Опубликовано 2017 Smashing Media AG, Фрайбург, Германия.
Все права защищены.
ISBN (ePUB): 978-3-945749-59-3
Дизайн обложки: Эспен Брунборг.
Вычитка: Оуэн Грегори.
Производство электронных книг: Cosima Mielke.
Макет печати: Маркус Сейферт.
Проектирование систем было написано Аллой Холматовой и рецензировано Карен МакГрейн и Джереми Кейтом.
Пожалуйста, присылайте ошибки по адресу: errata@smashingmagazine.com
Алёне
7. Планирование и практичность
8. Систематизация функциональных паттернов
Алла Холматова - дизайнер UX и взаимодействия с девятилетним опытом работы в Интернете для целого ряда продуктов и компаний. Совсем недавно она работала старшим дизайнером на платформе открытого образования FutureLearn.
Она особенно заинтересована в системах проектирования, языке и способах совместной работы. В последние два года этот интерес привел ее к тому, что она потратила огромное количество времени на работу и исследование предмета. Она делится своими мыслями с людьми через статьи, семинары и проекты. Алла участвует в разработке публикаций, таких как A List Apart, и выступает на конференциях по всему миру.
За последние двадцать лет Карен Макгрейн помогла предприятиям создавать более совершенные цифровые продукты с помощью дизайна пользовательского опыта и стратегии контента. Она является управляющим партнером в Bond Art + Science, консалтинговой компании UX, которую она основала в 2006 году, а ранее - вице-президент и национальный лидер в области пользовательского опыта в Razorfish. Карен преподает дизайн-менеджмент в программе MFA in Interaction Design в Школе визуальных искусств на Манхэттене. Она является соведущим подкастом «Отзывчивый веб-дизайн» с Итаном Маркоттом, и ее первая книга « Стратегия контента для мобильных устройств 1» была опубликована в 2012 году издательством A Book Apart.
Джереми Кит является соучредителем и техническим директором в Clearleft, студии цифрового дизайна, базирующейся в Брайтоне, Англия. Когда он не создает веб-сайты, он говорит на конференциях о создании веб-сайтов. Иногда он даже пишет книги о создании веб-сайтов, например, веб-книгу на ResilientWebDesign.com, которую вы можете получить бесплатно. Но он в основном тратит свое время на безделье в Интернете, документируя свою трату времени на своем сайте adactio.com, где он пишет более пятнадцати лет.
Если у вас есть минутка, посмотрите работы художника Эмили Гарфилд. Она создает изысканные, замысловатые карты в акварели - каждая из них потрясающая, и каждая из них изображает место, которого не существует. Вместо того, чтобы изображать реальный, реальный ландшафт города, она начинает с создания единого сложного узора - дороги с узлами, извилистой реки или компактной сетки городских кварталов - и повторяет ее. Гарфилд перебирает этот паттерн, каждый раз слегка меняя его, постепенно увеличивая до тех пор, пока ее не-карта не закончится. В результате ее искусство обладает генеративным, фрактальным качеством: оно построено из узоров, да, но ощущается как единое целое.
На самом деле Гарфилд однажды сказал: «Я описываю свой процесс как выращивание рисунка» . Читая эту замечательную книгу Аллы Холматовой - эту книгу, которую вы собираетесь читать - я много думал об этой строке. Может быть, вы тоже.
В последние годы веб-дизайнеры начали использовать более модульные, основанные на шаблонах методы проектирования. И на то есть веская причина: нас просят создать впечатляющий опыт для большего количества экранов, большего количества устройств, большего количества мест, большего количества людей, чем когда-либо прежде. В результате мы начали разбивать наши интерфейсы на крошечные многократно используемые модули и начали использовать эти шаблоны для создания продуктов, функций и интерфейсов быстрее, чем когда-либо прежде.
Но сами по себе шаблоны проектирования не достаточно. Они должны жить в более широком процессе, который гарантирует, что эти маленькие интерфейсные модули чувствуют себя едиными, связными, связанными. Часть целого. Другими словами, им нужна система дизайна, чтобы процветать - и вот тут-то и появляется книга Аллы.
На этих страницах Алла показывает нам, как именно создавать системы для поддержки наших цифровых проектов. С ясным написанием, тематическими исследованиями и подробными примерами Алла показывает нам, как установить общий, общий язык для наших команд, который позволяет нам более эффективно сотрудничать; она расскажет истории о том, как разные организации создали свои системы проектирования, и применяет их на практике; и она обсудит различные модели развития этих систем с течением времени.
Другими словами, это не просто книга. Алла нарисовала для нас ясную, яркую карту, которая обрисовывает в общих чертах более устойчивую модель для цифрового дизайна. И если мы пойдем по пути, который она для нас наметила, мы научимся совершенствовать системы проектирования - а вместе с ними - и лучшие проекты.
- Итан Маркотт
Поскольку сеть продолжает быстро меняться и становиться все более сложной, думать об этом с точки зрения статических страниц стало несостоятельным, и многие из нас начали подходить к дизайну более систематическим образом.
И все же не все системы проектирования одинаково эффективны. Некоторые могут генерировать согласованные пользовательские интерфейсы, другие создают запутанные лоскутные конструкции. Некоторые вдохновляют команды вносить в них свой вклад, другие пренебрегают. Некоторые поправляются со временем, становятся более сплоченными и лучше функционируют; другие становятся хуже, становятся раздутыми и громоздкими.
Каковы ключевые качества хорошо функционирующей, устойчивой системы проектирования? Этот вопрос заинтриговал меня так сильно, что я потратил огромное количество времени на исследования и размышления об этом. Мои исследования и мысли составляют основу этой книги. Опираясь на опыт компаний разных размеров и подходов к проектированию систем, я решил определить, что делает эффективную систему, которая позволяет командам создавать великолепные цифровые продукты. В книге я расскажу о подходе, который помогает мне каждый день в моей работе. Я надеюсь, что это поможет и с вашей работой.
Эта книга ориентирована в основном на небольшие и средние группы разработчиков, пытающиеся интегрировать мышление систем проектирования в культуру своей организации. Чтение этой книги может принести пользу всем членам группы разработчиков продуктов, но особенно дизайнерам визуальных и интерактивных приложений, специалистам по UX и разработчикам интерфейсов.
В этой книге представлен взгляд на системы проектирования, основанный на моем опыте интерактивного и визуального дизайна. Я не касаюсь других смежных областей, таких как информационная архитектура, контент-стратегия или исследования дизайна. В равной степени это не техническая книга. Вы не найдете примеров кода или углубленного анализа инструментов и методов разработки, хотя будет много дискуссий, непосредственно связанных с интерфейсными методами.
Это книга о дизайне, но она не о том, что делать. Это также не попытка создать всеобъемлющее руководство по разработке цифровых продуктов. 1 Речь идет о том, как подходить к процессу проектирования более систематически и обеспечить, чтобы ваша система проектирования помогла достичь цели вашего продукта и соответствовала культуре вашей команды.
Книга состоит из двух частей.
В первой части мы поговорим об основах системы проектирования - шаблонах и практиках . Шаблоны дизайна - это повторяемые, многократно используемые части интерфейса, от конкретных и функциональных (например, кнопок и текстовых полей) до более наглядных (таких как стили значков, цвета и типографика). Шаблоны взаимосвязаны, и вместе они образуют язык интерфейса вашего продукта. Общие методы - это то, как мы выбираем создание, сбор, совместное использование и использование этих шаблонов - следуя набору принципов или сохраняя библиотеку шаблонов.
Система дизайна не может быть построена в одночасье - она постепенно развивается вместе с вашим продуктом. Но есть определенные принципы и практики, которым мы можем следовать, чтобы убедиться, что система развивается в правильном направлении и обеспечить нам некоторую степень контроля над ней. Вторая часть книги посвящена практическим шагам и методам создания и поддержания системы проектирования, в том числе: планированию работы; проведение инвентаризации интерфейса; настройка библиотеки шаблонов; создание, документирование, развитие и поддержание шаблонов проектирования.
Прежде чем мы углубимся в тему, давайте определимся с терминами, которые мы будем использовать на протяжении всей книги.
Шаблон или шаблон дизайна
Я использую слово « шаблон» для обозначения любых повторяющихся, повторно используемых частей интерфейса (таких как кнопки, текстовые поля, стили значков, цвета и типографика, повторяющиеся пользовательские потоки, интерактивное поведение), которые можно применять и повторно использовать для решения конкретная проблема дизайна, удовлетворить потребности пользователя или вызвать эмоции. На протяжении всей книги я различаю функциональные паттерны, связанные с поведением , и перцептивные паттерны, связанные с брендом и эстетикой .
Функциональные шаблоны или модули
Эти термины используются в книге взаимозаменяемо для обозначения материальных строительных блоков интерфейса, таких как кнопка, заголовок, элемент формы, меню.
Шаблоны или стили восприятия
Это более наглядные и менее осязаемые шаблоны дизайна, такие как стили иконографии или цвета и типографика, обычно используемые для создания определенного вида эстетики и усиления эмоциональной связи с продуктом.
Язык шаблонов или язык дизайна
Набор взаимосвязанных, совместно используемых шаблонов дизайна формирует язык интерфейса вашего продукта. Язык шаблонов сочетает в себе функциональные и перцептивные шаблоны, а также шаблоны для конкретных платформ (например, меню гамбургеров), шаблоны доменов (например, модули, специфичные для сайта электронной коммерции, или финансовое программное обеспечение, или социальное приложение), UX и убедительные шаблоны и многие другие типы объединены в интерфейсе для конкретного продукта.
Система дизайна или система
В веб-сообществе не существует стандартного определения «системы дизайна», и люди используют этот термин по-разному, иногда взаимозаменяемо с «руководствами по стилю» и «библиотеками шаблонов». В этой книге по системе дизайна Я имею в виду набор связанных шаблонов и общих практик , согласованно организованных для использования в целях цифрового продукта.
Библиотека шаблонов и руководство по стилю
Библиотека шаблонов - это инструмент для сбора, сбора и обмена шаблонами дизайна и рекомендациями по их использованию. Создание библиотеки шаблонов является примером (хорошей) практики проектирования. Традиционно руководство по стилю фокусируется на стилях, таких как стили иконографии, цвета и типографика, а библиотека шаблонов включает в себя более широкий набор шаблонов.
Книга основана на практических взглядах из реальных продуктов. Большинство из них основаны на моем опыте работы в FutureLearn 2 , средней компании открытого образования в Лондоне. В течение трех лет работы там в качестве дизайнера я имел возможность наблюдать и влиять на то, как развивается система проектирования, от первоначальных концепций до зрелой системы 3 .
Для большей глубины и разнообразия в исследованиях я также внимательно следил за пятью другими компаниями разных размеров и подходов к проектированию систем: Airbnb, Atlassian, Eurostar, Sipgate и TED. В течение 18 месяцев я брал интервью у членов их команд, чтобы понять непосредственно от команды, проблемы, с которыми они сталкиваются по мере развития их систем. Компании, которые любезно согласились поделиться своим мнением, заключаются в следующем.
Во время интервью в августе 2016 года Рой Стэнфилд (главный дизайнер по взаимодействию) подробно рассказал мне о Системе языка проектирования 5 на Airbnb. Отличительной чертой DLS является ее строгость. Шаблоны указаны и используются точно, а правила строго соблюдаются. Команда разработала ряд методов и инструментов для достижения этой цели. У них все еще есть некоторые проблемы с принятием, быстротой интеграции новых шаблонов, а также с синхронизацией художественного руководства и разработки.
Юрген Спангл (руководитель отдела дизайна), Джеймс Брайант (ведущий дизайнер) и Кевин Коффи (менеджер по дизайну) поделились своими взглядами на ADG ( Atlassian Design Guidelines 7 ) в ноябре 2016 года. Несмотря на то, что есть специальная команда, которая разрабатывает шаблоны, у них также есть модель с открытым исходным кодом для вкладов. Каждому в компании не только разрешено, но и активно предлагается внести свой вклад в систему. Задача этой модели состоит в том, чтобы найти баланс между предоставлением людям достаточной свободы для участия, но при этом следить за тем, чтобы система оставалась управляемой и курированной.
Дэн Джексон (Архитектор решений) был очень рад в августе и сентябре 2016 года и в марте 2017 года о том, что они делали в Евростар. На момент написания этой статьи команда находилась в процессе создания своей первой библиотеки шаблонов 9 . Изначально они столкнулись с некоторыми проблемами, особенно с определением приоритетов проекта и поощрением каждого члена команды внести свой вклад. Через год им были выделены ресурсы для выделения выделенной команды, которая сейчас ведет работу над системой.
Тобиас Риттербах (владелец опыта) и Матиас Вегенер (веб-разработчик) дали мне глубокое понимание своей работы в августе 2016 года и ноябре 2016 года. Библиотека шаблонов Sipgate 11 была создана в 2015 году, но спустя год команда обнаружила, что слишком много шаблонов, в основном из-за отсутствия связи между группами разработчиков. Совсем недавно они работали над новой библиотекой шаблонов, целью которой было объединить язык проектирования на нескольких веб-сайтах продуктов.
Майкл МакВаттерс (UX Architect), Аарон Вайенберг (UX Lead) и Джо Бартлетт (Front-End Developer) внесли свой вклад в дискуссии в августе и сентябре 2016 года. Среди множества людей, которые поддерживают TED.com, небольшая группа практиков UX и Фронтальные разработчики несут ответственность за решения системы проектирования. У команды есть глубокие общие знания об их шаблонах, которые задокументированы простым способом 13 . До сих пор они не чувствовали необходимости в создании всеобъемлющей библиотеки шаблонов.
Я хочу поблагодарить всех в FutureLearn за поддержку этой книги, в частности: Люси Блэквелл, за рецензирование ранних черновиков, а также за то, что они направляли и вдохновляли меня на то, чтобы сделать мою лучшую работу; Майк Шарплз, за заставляющую задуматься отзыв о раннем наброске и за то, что бросил мне вызов Габора Вайда, за помощь в формировании многих идей, описанных в книге; Jusna Begum, за то, что я привнес в порядок некоторые хаотические мысли; и Сэм Мактаггарт, Довиле Сандайт, Киран Макканн, Шторм Макспорран, Кэти Коулман, Ники Томпсон, Джеймс Мокетт, Крис Лоуис и Мэтт Уолтон, за то, что они нашли время, чтобы послушать и поделиться своими отзывами.
Огромное спасибо команде Smashing и всем, кто помог мне создать эту книгу и воплотить ее в жизнь. Особая благодарность Карен МакГрейн, Джереми Кейту и Виталию Фридману за вдумчивые и конструктивные отзывы, которые сделали эту книгу намного лучше; Оуэна Грегори, за редактирование книги; Итану Маркотту за предисловие; и Эспен Брунборг за красивый дизайн обложки.
Я особенно хотел бы поблагодарить многих людей, которые любезно согласились поделиться своим опытом и перспективами, многие из которых внесли свой вклад в материал в книге: команды, упомянутые в Design Systems Insights, а также Сара Драснер, Лаура Элизабет, Мэтт Бонд, Трент Уолтон, Джери Коуди, Джоэл Берджес, Михал Парашидис, Хейдон Пикеринг, Леони Уотсон, Бетани Сонефельд и Крис Дханарадж (IBM), Эми Тибодо (Shopify) и Джо Престон (Intuit).
Наконец, я хочу поблагодарить мою семью: моего мужа Хакана и мою маленькую дочь Алену за терпение и понимание, которые они дали мне за те 18 месяцев, которые потребовались для подготовки окончательного проекта. Написание книги при работе на полный рабочий день было огромным трудом, и это было бы невозможно без поддержки моего мужа. Извини, Алена, за все то время, когда я не могла играть с тобой, потому что была занята работой. Я люблю тебя и обещаю наверстать упущенное!
-
1. Для этого я рекомендую « О лице: основы интерактивного дизайна » Алана Купера; Джефф Готельф и Джош Сейден, « Lean UX: применение принципов Lean для улучшения пользовательского опыта »; и проектирование в эпоху цифровых технологий: как создавать ориентированные на человека продукты и услуги , Ким Гудвин.
2. https://www.futurelearn.com/
3. https://www.futurelearn.com/pattern-library
5. http://smashed.by/airbnblanguage
9. https://style.eurostar.com/
В веб-сообществе нет стандартного определения «системы дизайна», и люди используют этот термин по-разному. В этой главе мы определим, что такое система проектирования и из чего она состоит.
Система проектирования - это набор взаимосвязанных шаблонов и общих практик, согласованно организованных для использования в целях цифрового продукта. Шаблоны - это повторяющиеся элементы, которые мы объединяем для создания интерфейса: такие как пользовательские потоки, взаимодействия, кнопки, текстовые поля, значки, цвета, типографика, микроскопия. Практики - это то, как мы выбираем для создания, захвата, обмена и использования этих шаблонов, особенно при работе в команде.
Взгляните на эти два экрана не связанных продуктов. Один из них - от Thomson Reuters Eikon, приложения для торговли и анализа рынка; другой от FutureLearn, сайта социального обучения с открытым образованием.
Экран от Thomson Reuters Eikon (слева) и экран от FutureLearn (справа).
В каждом примере шаблоны работают вместе для достижения разных целей. Для Thomson Reuters это обработка данных, утилиты, быстрое сканирование и многозадачность; для FutureLearn - это вдумчивое чтение, неформальное обучение, рефлексия и общение с единомышленниками. Цель продукта формирует шаблоны дизайна , которые она принимает.
Макет Thomson Reuters основан на панелях и виджетах, что позволяет пользователям работать в многозадачном режиме. Дизайн плотный, вмещающий большое количество информации на экране. Плотность достигается за счет узкого расстояния, компактного управления, гибких макетов и типографского выбора, таких как сжатый шрифт и относительно небольшие заголовки. С другой стороны, раскладка FutureLearn намного просторнее. Каждый экран обычно фокусируется на одной задаче, такой как чтение статьи, участие в обсуждении или выполнение интерактивного упражнения. Макет здесь в основном один столбец; есть высококонтрастная типография с большими заголовками, короткими элементами управления и большим пробелом. 1
На выбор шаблонов дизайна влияют многие факторы. Некоторые из них происходят из домена, к которому принадлежит продукт, и из его основной функциональности: это функциональные шаблоны . Например, чтобы использовать программное обеспечение для торговли и анализа рынка, вам нужно привыкнуть к панелям задач, полям и сеткам данных, диаграммам и инструментам визуализации данных. Для сайта онлайн-обучения это могут быть статьи, видео, темы для обсуждения, индикаторы прогресса и интерактивные действия. Сайт электронной коммерции, скорее всего, будет включать в себя отображение товара, фильтры списка, корзину покупок и оформление заказа.
Этос продукта (или бренд, в зависимости от вашего определения бренда) также образует узоры , которые вместе формируют , как продукт воспринимается; в этой книге я буду ссылаться на них как на шаблоны восприятия . Под этим я подразумеваю такие вещи, как тон голоса, типография и выбор цвета, стили иконографии, интервалы и макет, конкретные формы, взаимодействия, анимация и звуки. Без шаблонов восприятия вы не почувствуете большой разницы между продуктами в пределах одного домена, которые имеют схожую функциональность.
Хотя HipChat и Slack имеют схожие цели и функциональность, они чувствуют себя совершенно по-разному, в основном из-за того, как бренд выражается во всех их интерфейсах.
Шаблоны также формируются в соответствии с соглашениями платформы. Продукт может чувствовать себя отчетливо веб-или явно из-за языка разработки для конкретной платформы. Приложение iOS для продукта может вести себя совершенно иначе, чем его аналог для Android.
Когда дело доходит до создания цифрового продукта, в игре много разных моделей. Вот почему дизайн это сложно. Шаблоны должны взаимодействовать, соединяться, но вместе с тем работать без сбоев. Давайте внимательнее посмотрим на них.
Идея дизайна шаблонов была представлена архитектором Кристофером Александром в его оригинальных книгах «Вечный путь строительства и язык шаблонов» . Один вопрос, который звучит в книгах, заключается в том, почему некоторые места чувствуют себя такими живыми и замечательными, а другие - скучными и безжизненными. По словам Александра, то, как места и здания заставляют нас чувствовать себя, связано не только с субъективными эмоциями. Это результат определенных материальных и специфических моделей. Даже обычные люди могут учиться и использовать их для создания гуманной архитектуры.
Шаблон - это повторяющееся, многократно используемое решение, которое можно применять для решения проблемы проектирования.
«Каждый шаблон описывает проблему, которая возникает снова и снова в нашей среде, а затем описывает ядро решения этой проблемы».
- Кристофер Александр, Язык шаблонов
Язык шаблонов содержит 253 шаблонов архитектурного дизайна, начиная с более крупных, таких как макет города и дорожных систем, и заканчивая самыми маленькими, такими как освещение и мебель в семейном доме.
Аналогично, при создании интерфейсов мы используем шаблоны проектирования для решения общих проблем: мы используем вкладки, чтобы разделить контент на разделы и указать, какая опция выбрана в настоящее время; мы используем раскрывающийся список для отображения списка параметров по запросу пользователя. 2
Некоторые из шаблонов Bootstrap, интерфейсной среды для разработки адаптивных веб-сайтов.
Мы используем шаблоны для предоставления обратной связи, чтобы показать, сколько шагов осталось в процессе, чтобы позволить людям взаимодействовать друг с другом, просматривать и выбирать элементы. Шаблоны проектирования могут интриговать и поощрять, облегчать задачи, создавать чувство достижения или иллюзию контроля.
Пример убедительного паттерна «распознавание по отзыву» на паттернах пользовательского интерфейса 3 .
Большинство шаблонов дизайна установлены и знакомы. Они используют ментальные модели людей и позволяют интуитивно понимать дизайн. Совершенно новые шаблоны требуют, чтобы пользователи сначала изучали и принимали их - они относительно редки. 4 То, что отличает продукт от конкурентов, заключается не в новизне шаблонов, которые он использует, а в том, как эти шаблоны выполняются и применяются, и как они соединяются для достижения цели проектирования. Набор взаимосвязанных шаблонов формирует язык дизайна интерфейса вашего продукта.
Язык дизайна появляется, когда мы работаем над продуктом. Мы не всегда знаем, что это за язык. Иногда эффективные и интересные проекты основаны на интуиции, и мы изо всех сил пытаемся четко сформулировать, как и почему они работают. Дизайнеры и разработчики могут знать это инстинктивно, но интуиция не всегда надежна или масштабируема. В своей статье « Исследование систем дизайна » 7 дизайнер Дэн Молл отметил, что одной из основных целей системы дизайна является «расширение креативного направления». Если вам нужно, чтобы группа людей следовала креативному направлению последовательно, надежно и согласованно шаблоны должны быть четко сформулированы и распространены .
Когда вы формулируете свой язык дизайна, он становится действенным и воспроизводимым. Вы начинаете подходить к дизайну, имея в виду систему. Например, вместо того, чтобы обсуждать, как настроить элемент, чтобы сделать его более заметным, у вас может быть набор рекламных шаблонов, каждый из которых предназначен для достижения различного уровня визуальной значимости. Руководство по визуальной громкости 6 Тома Осборна (Tom Osborne) является примером того, как можно систематически обращаться к кнопкам и ссылкам. Вместо того, чтобы перечислять их по отдельности, они представлены в виде набора, каждый из которых имеет различный «объем», соответствующий его предполагаемому визуальному значению.
Руководство по визуальной громкости Тома Осборна.
Изложение вашего языка позволяет вам получить больше контроля над системой. Вместо того, чтобы делать небольшие изменения, вы можете повлиять на это гораздо более глубоко. Если вы обнаружите небольшое изменение дизайна, которое оказало положительное влияние на пользовательский опыт, вы можете применить его к шаблону в системе, а не к одному месту. Вместо того, чтобы тратить часы на разработку раскрывающегося списка, вы можете потратить это время на пользователей и экспертов по доменам, прежде всего выясняя, нужен ли раскрывающийся список. Когда язык проектирования является общим знанием, вы можете перестать фокусироваться на самих шаблонах и вместо этого сосредоточиться больше на пользователе.
На протяжении всей книги мы будем много говорить о формулировании, совместном использовании и документировании языка шаблонов для цифровых продуктов. В частности, мы рассмотрим два типа шаблонов проектирования: функциональные и перцептивные. Функциональные шаблоны представлены в виде конкретных модулей интерфейса, таких как кнопка, заголовок, элемент формы, меню. Шаблоны восприятия - это описательные стили, которые визуально выражают и передают индивидуальность продукта, такие как цвет и типография, иконография, формы и анимация.
Чтобы расширить аналогию с языком, функциональные паттерны немного похожи на существительные или глаголы - это конкретные, действенные части интерфейса; тогда как модели восприятия похожи на прилагательные - они описательны. Например, кнопка - это модуль с четкой функцией: разрешить пользователям отправлять действия. Но типографский стиль в метке кнопки, ее форма, цвет фона, отступы, интерактивные состояния и переходы не являются модулями. Это стили; они описывают, что это за кнопка. С точки зрения внешнего интерфейса модули всегда имеют основу в HTML, а шаблоны восприятия обычно являются свойствами CSS.
Система проектирования содержит множество других типов шаблонов: пользовательские потоки (например, заполнение форм с ошибками и сообщениями об успехах), шаблоны проектирования, ориентированные на предметную область (например, шаблоны обучения для систем EdTech и шаблоны электронной торговли), и убедительные шаблоны UX. Основное внимание в этой книге уделяется функциональным и перцептивным паттернам как основным строительным блокам системы проектирования.
Но, конечно, важны не только сами шаблоны, но и то, как они развиваются, делятся, связываются и используются.
Язык является основой сотрудничества. Если вы работаете в команде, ваш язык дизайна должен быть общедоступным для людей, участвующих в создании продукта. Без общего языка группа людей не сможет эффективно создавать вместе - у каждого человека будет своя ментальная модель того, чего он пытается достичь. Давайте вернемся к примеру кнопки. Даже такая базовая единица интерфейса может иметь разные значения. Что именно кнопка? Выделенная область, на которую вы можете нажать? Интерактивный элемент на странице, которая ссылается где-то? Элемент формы, который позволяет пользователям отправлять некоторые данные?
В своей книге « Как разобраться в любом беспорядке» Эбби Коверт предлагает установить общий язык, прежде чем думать об интерфейсах, обсуждая, проверяя и документируя наши языковые решения. Эта идея может быть применена для описания концепций высокого уровня, а также повседневного языка, который мы используем для обсуждения проектных решений. Наличие общего языка означало бы, что у нас одинаковый подход к именованию элементов интерфейса и определению шаблонов проектирования или что одни и те же имена используются в файлах проектирования и архитектуре интерфейса.
Даже этого может быть недостаточно. Иногда люди в группе думают, что они достигли взаимопонимания, потому что у них один и тот же словарный запас и он используется выразительно, но они все еще сохраняют фундаментальные различия в понимании. Например, после года использования термина «Сценарий» в качестве ключевого понятия в проекте вы можете обнаружить, что разные люди интерпретируют его совершенно по-разному. Речь идет не только о разработке общего языка - нам нужно также развивать совместное использование языка . Недостаточно общего понимания термина « кнопка» . Люди также должны знать, почему и как использовать кнопку, в каком контексте и для чего служит кнопка.
Предположим, что мы используем элемент «Sequence» в интерфейсе. Представляя его как «Последовательность», мы стремимся сообщить пользователям, что шаги следует рассматривать в определенном порядке.
Пример модуля «Последовательность».
В идеале, каждый, кто участвует в создании продукта, должен знать, что это за элемент: его название и назначение, почему он был разработан таким образом, и как и когда его следует использовать. 7 Чем сильнее это общее знание, тем больше шансов, что оно будет использовано надлежащим образом. Дизайнеры и внешние разработчики должны обладать этими знаниями, но это помогает, если люди из других дисциплин (контент, маркетинг, управление продуктами) тоже имеют представление.
Он должен быть известен всем как «Последовательность», а не «Элемент управления Wizard» или «Необычные пузыри». Если дизайнеры называют его «Необычные пузырьки», разработчики называют его «Элемент управления Wizard», а пользователи интерпретируют его как набор дополнительных вкладок, тогда вы знаете, что ваш язык не работает. Почему важна интерпретация пользователя? Здесь мы можем вспомнить новаторскую работу Дона Нормана « Дизайн повседневных вещей» , где он говорит о пропасти между образом системы (интерфейсом) и моделью пользователя (восприятием интерфейса, сформированного пользователем посредством взаимодействия с ним). Если у пользователя есть ментальная модель взаимодействия, которая не соответствует системному образу, предоставленному командой разработчиков, то пользователь будет постоянно сталкиваться с неожиданным поведением системы.Эффективный язык проектирования устраняет разрыв между образом системы и (предполагаемой) моделью пользователя.
По мере того, как ваш язык становится все богаче и сложнее, вам нужен эффективный способ его захвата и обмена. В современной сети библиотека шаблонов является одним из ключевых примеров хорошей практики поддержки системы проектирования.
Система проектирования состоит не только из шаблонов, но также из методов и практик для создания, захвата, совместного использования и развития этих шаблонов. Библиотека шаблонов - это инструмент для сбора, хранения и обмена шаблонами проектирования, а также принципы и рекомендации по их использованию. Несмотря на то, что библиотеки шаблонов стали популярными в Интернете сравнительно недавно, концепция документирования и совместного использования шаблонов проектирования в различных формах существует уже давно.
«Четыре книги архитектуры» Палладио , впервые опубликованные в 1570 году в Венеции, являются одной из самых важных и влиятельных книг по архитектуре. Это также один из самых ранних примеров системной документации. Черпая вдохновение из греко-римской архитектуры, Палладио предоставил правила и словарь для проектирования и строительства зданий, включая принципы и схемы, с подробными иллюстрациями и объяснениями их работы.
Типы лестниц: спиральные, овальные и прямые. Палладио описал, как и когда использовать каждый тип; например, винтовые лестницы подходят для «очень ограниченных мест, потому что они занимают меньше места, чем прямые лестницы, но труднее подняться».
В современном графическом дизайне системы также давно документированы, от ранней типографики и сеточных систем до принципов проектирования Баухауза. В течение последних нескольких десятилетий компании документировали свою визуальную идентификацию в форме руководств по брендам, причем одним из наиболее известных примеров является Руководство по стандартам графики НАСА от 1975 года.
Рекомендации по компоновке в Руководстве по графическим стандартам НАСА.
В Интернете библиотеки шаблонов начинались как расширенные документы, удостоверяющие личность бренда, которые фокусировались на обработке логотипа, корпоративных ценностях и стилях бренда, таких как типография и цветовые палитры. 8 Затем они были расширены, чтобы включить интерфейсные модули, а также рекомендации по их использованию. Библиотека шаблонов Yahoo была одним из первых примеров документированных шаблонов интерфейса.
Библиотека шаблонов Yahoo была одним из первых примеров документированных шаблонов интерфейса.
Для компаний, которые менее изобретательны, чем Yahoo, библиотека шаблонов, как правило, размещается в PDF или вики, что означает, что она статична и ее трудно поддерживать в актуальном состоянии. Сегодня многие дизайнеры и разработчики стремятся создать более динамичную или «живую» библиотеку шаблонов, которая содержит шаблоны проектирования, а также живой код, используемый для их создания. Руководство по живому стилю или библиотека шаблонов - это не просто справочный документ, это фактические рабочие шаблоны, используемые для создания интерфейса для цифрового продукта.
Библиотека шаблонов MailChimp 9 является одним из наиболее влиятельных ранних примеров живых библиотек шаблонов в Интернете.
Библиотеки шаблонов иногда считаются взаимозаменяемыми с системами проектирования. Но даже самая полная и живая библиотека шаблонов - это не сама система. Это инструмент, который помогает сделать систему дизайна более эффективной.
Библиотека шаблонов не гарантирует более целостного и последовательного дизайна. Это может помочь исправить небольшие несоответствия или сделать кодовую базу более надежной, но сам по себе инструмент очень мало повлияет на работу пользователя. Никакая библиотека шаблонов не исправит плохой дизайн. Шаблоны все еще могут быть плохо спроектированы, неправильно использованы или объединены таким образом, что не работают в целом. Как отметил в своем интервью Майкл МакВаттерс, UX-архитектор из TED: «Даже шаблон SquareSpace может быть разрушен из-за небрежного мышления». И наоборот, продукт с согласованным пользовательским интерфейсом может быть создан без всеобъемлющей библиотеки шаблонов (как мы будем см. в главе 6 пример с системой проектирования TED).
Живая библиотека шаблонов связана с лучшим сотрудничеством. И все же вы можете оказаться в ситуации, когда его использует только небольшая группа людей, или может быть слишком много разрозненных шаблонов из-за отсутствия связи между командами. В актуальном состоянии библиотека шаблонов является глоссарием для общего языка. Но это не значит, что еще нет места для интерпретации. Именно дискуссии вокруг интерпретации часто являются ключом к успеху или провалу библиотеки шаблонов.
С другой стороны, библиотеки шаблонов иногда обвиняют в подавлении творчества, что приводит к созданию веб-сайтов общего вида. Но опять же, библиотека шаблонов отражает систему проектирования, стоящую за ней. Если ваша система принципиально жесткая и ограничивающая, библиотека шаблонов может выявить и подчеркнуть жесткость. Если это позволяет много творческих экспериментов, хорошая библиотека шаблонов может облегчить эксперименты.
Благодаря всем автоматизированным инструментам и генераторам гидов по стилю, доступным сегодня, настройка библиотеки компонентов может быть выполнена намного быстрее, чем в прошлом. Но без основы согласованной системы проектирования, которая объединяет шаблоны и практики, ее влияние будет ограниченным. Когда библиотека шаблонов используется для поддержки прочной основы языка проектирования, она становится мощным инструментом проектирования и совместной работы. До тех пор это коллекция модулей на веб-странице.
Эффективность системы проектирования может быть измерена тем, насколько хорошо ее различные части работают вместе, чтобы помочь в достижении цели продукта. Например, цель FutureLearn состоит в том, чтобы «вдохновлять обучение на протяжении всей жизни у всех и везде». Мы могли бы спросить, насколько эффективен язык разработки интерфейса, помогающий нам достичь этого, и насколько эффективны практики команды? Если интерфейс сбивает с толку, и люди не достигают своих целей, то язык дизайна не эффективен. Если на создание новой области сайта уходит слишком много времени, поскольку шаблоны необходимо каждый раз заново создавать, то мы знаем, что наши методы можно улучшить.Систему проектирования можно считать эффективной, если она сочетает в себе экономическую эффективность в процессе проектирования, а также эффективность и удовлетворенность пользовательского опыта в зависимости от цели продукта.
В книге «Мышление в системах» Донелла Медоус объясняет, что одним из наиболее важных качеств систем является то, как они связаны и организованы: подсистемы объединяются в более крупные системы, которые, в свою очередь, образуют часть чего-то большего. Клетка в вашей печени является частью органа, который является частью вас как организма. Ни одна система не существует в изоляции. Ваша система дизайна может иметь меньшую подсистему: редакционные правила для управления макетом страницы; или это может включать в себя метод для адаптивного масштабирования вашего логотипа определенным образом. В то же время, это также часть других более крупных систем: ваш продукт, ваша команда, культура вашей компании.
Эмблема Музея американского искусства Уитни, « динамическая буква W » 10, представляет собой простую, но удивительно легко адаптируемую систему. W отвечает на произведения искусства и слова вокруг него, предоставляя огромный спектр возможностей гибкой верстки.
В высокоэффективных системах мы видим, что подсистемы связаны и ориентированы на общую цель: подход к проектированию отражается в архитектуре внешнего интерфейса; шаблоны проектирования следуют руководящим принципам; язык шаблонов последовательно применяется в дизайне, коде и библиотеке шаблонов. Мы видим гармонию в том, как функционируют эти системы: их рабочий процесс более эффективен, а создаваемый ими пользовательский опыт ощущается более значимым и последовательным.
Когда есть пробелы, их также легко увидеть. Фрагментированная система проектирования приводит к фрагментированному пользовательскому опыту, полному противоречивых сообщений. Мы хотим, чтобы пользователь подписывался на нашу новостную рассылку, но мы также хотим, чтобы они проверяли наши последние продукты. Мы хотим, чтобы они продвинулись по шагам, но мы также должны убедиться, что они оценивают каждый рецепт. «Последовательность» используется для предварительного просмотра шагов в одной области сайта; в другом - это навигация с вкладками. Интерфейс полон различных оттенков одного цвета и нескольких версий одной и той же кнопки. На производительность команды также влияют: внесение крошечных изменений отнимает много времени и сложностей из-за запутанного, запутанного кода. Дизайнеры тратят свое время на копирование пикселей и переосмысление решений тех же проблем, а не на понимание и решение реальных потребностей пользователей.
Как уменьшить разрывы и сделать нашу систему проектирования более эффективной? Понимая, что это такое и как это работает. Мы начнем с рассмотрения того, как язык шаблонов развивается в новом продукте, на примере простого вымышленного десятиминутного веб-сайта с рецептами.
Представьте, что мы создаем веб-сайт для обмена рецептами с людьми, которые любят здоровую пищу, но не хотят тратить много времени на приготовление пищи. Если бы мы подошли к нему с учетом системы и на раннем этапе определили шаблоны проектирования, с чего бы нам начать? Прежде чем мы начнем, давайте сделаем некоторые предположения. Мы понимаем сферу кулинарии, и уже было проведено достаточное количество исследований для обоснования наших дизайнерских решений. Поэтому мы пытаемся не выяснить, каким должен быть опыт, но посмотреть, как мы можем разработать концепцию системы дизайна для этого нового веб-сайта.
Первое, что мы должны сделать, это попытаться понять, кто наши пользователи, их цели, потребности и мотивы. Для простоты, скажем, мы знаем, что они заняты профессионалами, и их цель - получить вкусную, полезную еду без хлопот и потраченных часов на приготовление пищи. Есть много способов помочь им в достижении этой цели: соединить их с поварами, доставить еду к их порогу, создать диалоговое приложение. Но мы хотим сделать это через веб-сайт с десятиминутными рецептами.
Если бы мы выразили цель в одном предложении, это было бы следующим образом: мотивировать и дать людям возможность готовить вкусные полезные блюда не более чем за десять минут. Эта цель является ядром продукта, и она должна принимать решения о дизайне и разработке. Команда должна признать эту цель и верить в нее - она не должна чувствовать себя вынужденной.
Другим важным элементом является дух, который отражает ценности и дух, которые мы пытаемся изобразить через сайт. Для нас это может быть простая здоровая пища и эксперименты с общими ингредиентами. Для других кулинарных сайтов это может быть высокая кухня и мастерство кулинарного мастерства.
Чтобы убедиться, что цель продукта четко выражена во всем, что мы делаем, нам нужно установить несколько основополагающих принципов и ценностей. Они могут быть обсуждены неофициально или написаны как манифест - важно, чтобы люди, участвующие в создании продукта, согласились с этими ценностями и обязались их соблюдать.
Например, все участники десятиминутной команды рецептов приготовления пищи понимают ценность времени. Они мотивированы наличием ограничения по времени для рецептов, и в результате они все стремятся сделать взаимодействие на сайте коротким, простым, быстрым и плавным. Этот принцип будет выражаться не только через шаблоны проектирования, но и за эффективность сайта, его тон голоса и даже то, как работает команда.
Эти принципы не обязательно должны быть официальными или даже записанными. Но наличие согласия и осведомленности в команде о том, что они собой представляют, важно для синхронизации усилий и приоритетов каждого. Он также может помочь в принятии решения: от какой функции сначала создать и какой подход использовать до разработки UX-потоков или как должны выглядеть кнопки и выбор гарнитуры. 11
Мы разработали некоторые из ключевых способов поведения, которые мы хотим поощрить или включить в наших пользователях, которые помогут им достичь своих целей.
• Мы хотим, чтобы люди всегда выбирали здоровую домашнюю еду вместо быстрой или приготовленной в микроволновке. Это означает, что наша еда должна выглядеть вкусно и полезно, и быть более соблазнительной, чем пища в микроволновке. Хорошие образы с неотразимо вкусной, но простой на вид едой могут помочь нам здесь.
• Мы хотим, чтобы люди смогли достичь хороших результатов менее чем за десять минут. Это означает, что нам нужно будет представить рецепты в несколько простых шагов. Шаги должны быть короткими, четкими и целенаправленными. Возможно, мы могли бы иметь таймер на каждом шаге, чтобы убедиться, что мы выполняем десятиминутное обещание.
• Мы хотим поощрять людей быть спонтанными и чувствовать, что они могут подготовить что-нибудь, когда захотят. Начните с того, что у вас уже есть, а не с того, что вам нужно - не нужно покупать экстравагантные ингредиенты. С точки зрения пользовательского интерфейса это может быть поддержано легко выбираемыми миниатюрами ингредиентов с четкими метками.
• Наконец, мы хотим побудить людей быть творческими, спонтанными и веселиться. Покажите, какие ингредиенты являются необязательными и на что их можно заменить. Покажите неожиданные комбинации, которые можно было бы попробовать попробовать. 12
Естественно, детали дизайна будут меняться по мере того, как мы будем работать над сайтом, но эти ключевые характеристики останутся прежними. Такое поведение будет информировать основные функциональные модули и взаимодействия сайта: миниатюры ингредиентов, карточки рецептов, последовательность шагов, таймер.
Примерно в то же время нам нужно будет понять, как мы хотим, чтобы кто-то воспринимал нас, используя сайт рецептов приготовления пищи за десять минут. Мы простые и практичные или гламурные и сложные? Мы серьезны или игривы? Смелый или подавленный? Утилитарный или эмоциональный? Какие эстетики отражают личность и дух, которые мы хотим изобразить через интерфейс? Мы бы начали думать о бренде.
Мы увлечены здоровой пищей, поэтому хотим, чтобы она проходила через сайт. Возможно, это будет иметь органическое, теплое, полезное ощущение. Мы также считаем, что для приготовления пищи не нужно много планирования и подготовки; это может быть спонтанно и весело, и вы можете экспериментировать и проявлять творческий подход в течение десяти минут.
В этот момент мы, вероятно, собрали бы несколько досок настроения и начали бы экспериментировать с визуальными эффектами, пока бренд не почувствует себя хорошо. 13 Как только мы достигнем этого, мы сможем определить основные визуальные элементы бренда, такие как типографика, цветовая палитра, тон голоса и любые отличительные черты бренда; например, иллюстрации, стили изображений, конкретные формы, уникальные взаимодействия, которые отражают суть нашего сервиса и представляют контент наилучшим образом.
Допустим, мы придумали теплую, естественную цветовую палитру, нарисованные от руки значки, типографику с акцентом на удобочитаемость, качественную фотографию здоровой пищи и несколько простых элементов интерфейса и элементов управления. Эти стили станут нашими моделями восприятия .
Наряду с этим процессом мы будем принимать языковые решения, выбирая ссылки на понятия определенным образом. Что такое «рецепт»? Что мы подразумеваем под «шагами»? Что делает «восхитительно простым» взаимодействие? Слова, которые мы выберем, будут влиять на то, как думает команда. И косвенно, они будут формировать дизайн.
Во-первых, шаблоны и выбор языка будут распространяться неформально. Но по мере того, как наша команда и продукт растут, язык будет расти. В конечном итоге нам потребуется более структурированный способ сбора, обмена и организации наших словарей дизайна. 14
Теперь, когда мы вкратце рассмотрели процесс проектирования с использованием вымышленного сайта, мы можем посмотреть, как развиваются системы, используя примеры из реальных цифровых продуктов и компаний.
-
1. Шаблоны на FutureLearn выбраны для поддержки рефлексивного обучения. Учащийся должен сосредоточиться на поставленной задаче и не отвлекаться на перемещения. Цель состояла в том, чтобы создать атмосферу, которая чувствует себя спокойной и созерцательной.
2. Шаблоны пользовательского интерфейса веб-сайта являются отличным источником общих шаблонов дизайна, сгруппированных по назначению и решаемой им проблеме дизайна. Для всестороннего прочтения шаблонов пользовательского интерфейса я также рекомендую проектирование интерфейсов: шаблоны для эффективного проектирования взаимодействий от Дженифер Тидуэлл.
3. http://smashed.by/patternsrecognition
4. Пока жест смахивания не станет мобильным шаблоном, никто не знал, как с ним работать. Теперь мы видим целые продукты, построенные по этому шаблону (например, Tinder). Переход к использованию того, что люди знают, и изучение чего-то нового очень деликатен; продукты живут и умирают в зависимости от того, когда и как они это делают.
5. http://smashed.by/researchingsystems
6. http://smashed.by/visualloudness
7. Задача также состоит не в том, чтобы навязать одно определение или концепцию «последовательности», а в том, чтобы понять и работать с ее контекстом использования, чтобы, например, команда UX могла поддерживать различные типы последовательности (для FutureLearn - последовательность курсов , работает, шаги, действия пользователя и т. д.) в согласованной структуре.
8. Возможно, именно так мы можем отличить руководства по стилю от библиотек шаблонов. Руководства по стилю традиционно ориентированы на такие стили, как цвет и типографика. Библиотеки шаблонов могут включать, среди прочего, стили, а также функциональные шаблоны и принципы дизайна.
9. http://smashed.by/mailchimppatterns
10. http://smashed.by/whitneyidentity
11. В следующей главе мы более подробно рассмотрим качества эффективных принципов дизайна и то, как они могут стать основой вашего языка дизайна.
12. Дополнительную информацию о понимании того, что хотят люди, и о формировании видения нового продукта см. В статье « Мы не продаем здесь седла » Стюарта Баттерфилда, генерального директора Slack.
13. Подробнее о процессе определения моделей восприятия в главе 4.
14. В главе 5 мы увидим, как эффективные имена и совместный процесс именования могут стать частью системы языкового дизайна. В главе 10 мы рассмотрим библиотеки шаблонов как способ выбора языка и создания общего словаря.
Твердые принципы являются основой для любой хорошо функционирующей системы. В этой главе мы обсудим качества эффективных принципов проектирования и рассмотрим некоторые способы их определения.
Ранее мы говорили о важности начинать с цели и характера продукта при разработке интерфейса. Четкое понимание цели имеет первостепенное значение, поскольку все остальные решения должны приниматься ею, даже косвенно. Как мы можем быть уверены, что цель продукта проявляется в дизайне? Установив несколько основополагающих ценностей и принципов.
В некоторых компаниях, особенно на ранних этапах, попытка сформулировать общие руководящие принципы может быть сложной. Принципы проектирования - это не то, что можно измерить и определить количественно, и их определение может занять несколько итераций. Там также может быть некоторая путаница о том, что именно принципы. В зависимости от компании, они могут быть более сосредоточены на бренде, культуре команды или процессе проектирования. Эти принципы в Pinterest 1 более ориентирована на продвижение бренда ( «Lucid», «анимированные», «Неуязвимый»), в то время как в Великобритании правительства Digital Service 2 (GDS) они направлены больше на том , как команда работает ( «Делайте меньше, «Итерация. Затем итерация снова»).
Иногда принципы используются в течение ограниченного времени, для конкретного проекта. Дизайнер Дэн Молл любит писать «манифест дизайна» в начале каждого проекта, чтобы быть уверенным, что творческое направление и цели четко выражены. 3 В других случаях принципы более долговечны, и их наследие становится частью корпоративного духа. Возьмите ценности Джека Даниэля «уверенность», «независимость» и «честность», которые остались неизменными в течение прошлого столетия. 4
Крупные компании могут иметь отдельные наборы принципов для пользовательского опыта, бренда и системы дизайна. 5 Кроме того, каждая команда, работающая в компании, может также иметь свои собственные командные принципы. В то время как для некоторых это работает, другие могут обнаружить, что наличие нескольких наборов руководящих принципов может способствовать фрагментации системы проектирования. В Atlassian, компании-разработчике программного обеспечения, принципы маркетинга и продукта изначально были разными. Со временем команда сблизила их, и теперь они работают над единым набором принципов с целью выработать общую философию для преодоления разрыва между дисциплинами маркетинга, продукта и поддержки.
«Это одна система. Принципы должны соединить точки ».
- Юрген Шпангл, руководитель отдела дизайна, Atlassian
Вместо того, чтобы иметь отдельный набор принципов для разных команд и частей системы, Atlassian стремится иметь несколько ключевых ценностей - таких как «Жирный», «Оптимистичный» и «Практичный, с подмигиванием» - проходя черезвсе точки соприкосновения в пути клиентов Atlassian. Хотя эти значения одинаковы на протяжении всего пути, они не представлены с одинаковым уровнем интенсивности на разных этапах. В областях продаж и маркетинга сайта много «смелости», чтобы продемонстрировать продукты и помочь людям понять их ценность. Но как только вы доберетесь до самого продукта и областей поддержки, вы получите больше опыта в том, как выполнить работу и убедиться, что люди способны быть максимально эффективными. Таким образом, смелость смягчается, а «практическое» значение смещается вверх. Как отметил Кевин Коффи, менеджер по дизайну Atlassian: «Никто не хочет смелой страницы поддержки».
Подходы к принципам проектирования уникальны для каждой компании и могут принимать разные формы. Принципы могут быть всеобъемлющими или более детальными, временными или длительными. Важно то, насколько эффективно они объединяют дизайнерское мышление и творческое направление в команде. В контексте этой книги принципы проектирования являются общими руководящими принципами, которые отражают суть того, что значит хороший дизайн для команды, и советами о том, как этого добиться ; другими словами, согласованные критерии того, что представляет собой хороший дизайн в вашей организации и для вашего продукта.
Независимо от вашего подхода, эффективные рекомендации обычно имеют эти общие черты.
Я уверен, что вы знакомы с этими принципами: «Просто. Полезно. Приятно ». Они вездесущи, мы слышим их повсюду. Нет никаких сомнений в том, что продукты, которые хорошо спроектированы, следуют определенному набору общих принципов (например, десять заповедей Дитера Рэмса о хорошем дизайне). Но качества, подобные этим, должны быть даны - они должны быть сделаны с помощью дизайна - наряду с другими проблемами, такими как доступность и производительность. До сих пор я не видел потребительский цифровой продукт, в котором основными принципами являются «Сложный», «Бесполезный» и «Больно работать».
Знание того, что ваш продукт должен быть полезным и приятным, не очень поможет при принятии дизайнерских решений, потому что эти качества можно интерпретировать различными способами. Что могло бы сделать их более полезными, так это точно знать, что эти слова значат для вашей команды и вашего продукта. Что влечет за собой инновации ? Когда дизайн считается полезным ? Как узнать, действительно ли это восхитительно ? Хорошие принципы дизайна определяют качества, которые можно интерпретировать по-разному, и обосновывают их в контексте конкретного продукта.
Давайте возьмем TED в качестве примера. Один из принципов дизайна TED - «Будь вне времени, а не передовой» . Слово « вне времени» относится не только к интерфейсу TED, но и ко всему бренду и подходу к дизайну. А это значит, что они не собираются внедрять новые технологии или вводить элементы дизайна ради следования тренду. Прежде всего, он должен служить цели и работать для максимально возможного числа пользователей. Для TED вне времени означает не только простоту, но и осознание стилистических особенностей, которые не приносят пользы пользователям. Например, команда не будет вводить эффект параллакса, даже если он ощущается очень актуально, если только он не решит реальную проблему дизайна.
Принцип должен предлагать практическое руководство по решению проблемы дизайна в контексте конкретного продукта. Сравните эти две версии одного из принципов FutureLearn:
« Сделай это просто. Сделай так, чтобы это было почти незаметно! Мы всегда должны работать над устранением трений на платформе, создавая опыт, который дает пользователям реальную свободу контента. Если нашу платформу легко понять, люди могут и будут использовать ее больше ».
Это утверждение имеет смысл - никто не может поспорить с необходимостью иметь простой и удобный интерфейс. Однако из этого совета неясно, что именно означает простота и как ее достичь. Сравните это с этой версией:
« Нет ненужных частей. Каждый элемент дизайна, от самого большого до самого маленького, должен иметь цель и способствовать достижению цели большего элемента, частью которого он является. Если вы не можете объяснить, для чего предназначен элемент, скорее всего, его там быть не должно ».
На практике на вопрос «Это просто?» Гораздо сложнее ответить объективно, чем «Содержит ли это ненужные части?». На последний можно ответить, пройдя через интерфейс и задав вопрос о назначении каждого элемента.
Чтобы сформулировать принципы более практичным образом, постарайтесь думать о них не как о чем-то, что должно звучать просто хорошо, а как о том, что предлагает действенный совет . Представьте, что в вашей команде появился новый человек, и вас попросили поделиться пятью вещами, которые наиболее важны при разработке вашего продукта. Если вы скажете им: «Нам нравится, что здесь все замечательно. Сделайте это восхитительно! », Вероятно, это не поможет им сделать свою работу. Вам необходимо определить, что такое восторг, и поделиться практическими примерами того, как он выглядит в контексте вашего интерфейса.
Давайте посмотрим на пару примеров принципов проектирования и как их можно сделать более практичными.
Смутно: « Поясни. »
Практично:« Только один номер один приоритет. Что вы хотите, чтобы ваши пользователи видели и делали в первую очередь? »
Смутно: « Сделай это просто. »
Практические:« Сделать это нерушимым. Точно так же, как детская игрушка, убедитесь, что она предназначена для исследования и не может быть неправильно использована ». 6
Смутно: « Сделайте это полезным. »
Практично:« Начните с потребностями. Если вы не знаете, что нужно пользователю, вы не сделаете правильную вещь. Проводите исследования, анализируйте данные, общайтесь с пользователями. Не делайте предположений ». 7
Но даже самый сформулированный принцип все еще можно интерпретировать различными способами. Ничто не может сделать принцип более практичным, чем соединить его с реальным примером, чтобы показать, как его можно применять на практике. Найдите конкретные части вашего интерфейса, где принцип четко представлен, и соедините их вместе. Можете ли вы указать на место, которое четко показывает «только один приоритет номер 1»? Можете ли вы продемонстрировать, как шаблон может быть действительно «нерушимым», несмотря на богатые взаимодействия?
Дизайн определяется выбором, который мы делаем. Должна ли эта страница быть более визуально живой или более утилитарной? Здесь уместно быть более игривым или более серьезным? Можем ли мы оправдать создание этого модуля более удобным за счет снижения его гибкости? Достигая некоторых вещей, мы часто должны говорить «нет» другим. Хорошие принципы дизайна помогают определить приоритет и баланс, даже если есть противоречивые факторы, которые необходимо учитывать. 8
В качестве примера возьмем принципы системы дизайна освещения Salesforce 9 : «Ясность. Эффективность. Согласованность. Красота ». Подчеркивается, что они должны применяться в порядке приоритета выше. Красота не должна повышаться за счет эффективности или последовательности, и ясность всегда должна быть на первом месте. Ранжирование принципов таким образом сообщает команде, что должно быть приоритетным при принятии проектных решений.
Может быть полезно признать противоречивые значения и предложить, как найти баланс. Одним из ранних принципов проектирования в Medium было «Направление над выбором». На этот принцип часто ссылались при разработке редактора Medium. Они намеренно обменялись различными вариантами форматирования для руководства и направления, чтобы люди могли сосредоточиться на письме. 10
Несколько вариантов, доступных в минимальном редакторе Medium, ясно иллюстрируют один из принципов Medium, «Направление над выбором».
Хорошие принципы не пытаются быть всем для всех. Они имеют голос и активно поощряют дизайнера взглянуть в будущее. Эта идея была подчеркнута Дэном Моллом в « Исследовании систем проектирования 11 »:
«Система дизайна должна иметь руководящие принципы для: перспективы, точки зрения, расширения творческого направления для всех, кто решает построить что-то с помощью системы дизайна. Этот материал должен быть выпечен. В противном случае, мы все могли бы также использовать Material Design и назвать это днем ».
- Дэн Молл
Вот веселый тест. Попробуйте спросить людей в вашей компании, каковы ваши принципы дизайна. Если никто не может их запомнить, скорее всего, их можно улучшить. Чтобы быть запоминающимся, принципы должны постоянно использоваться. Они должны упоминаться в повседневных разговорах, включаться в презентации и критику дизайна, отображаться там, где их можно увидеть. И чтобы быть в использовании, они должны быть действительно полезными, обладая вышеуказанными качествами.
Это также помогает не иметь их слишком много. Человеческая память ограничена, и запоминание более четырех вещей одновременно может быть трудным. 12 Оптимальное количество принципов проектирования - если вы хотите, чтобы они использовались - составляет от трех до пяти. Когда команды в TED, Atlassian и Airbnb спросили об их принципах проектирования во время интервью для этой книги, они все смогли вспомнить их мгновенно. Не было ни малейшего колебания; никто не запутался и не попытался найти принципы в руководстве по бренду. Как они могли их так хорошо запомнить? Их принципы были просты, понятны, полезны - и их было не много.
Самое главное, команды использовали их ежедневно для принятия проектных решений. Четыре принципа проектирования Airbnb («Унифицированный», «Универсальный», «Культовый», «Разговорный») глубоко укоренились в процессе проектирования:
«Когда мы разрабатываем новый компонент, мы хотим убедиться, что он охватывает все четыре компонента . Если бы у нас не было набора принципов, было бы трудно договориться о вещах. Мы хотим убедиться, что каждый кусок соответствует этому ».
- Рой Стэнфилд, главный дизайнер по взаимодействию, Airbnb
Команда Spotify придумала аббревиатуру TUNE (тон, пригодный для использования, необходимый, эмоциональный), чтобы сделать их принципы дизайна более запоминающимися. Вопрос о том, находится ли дизайн «в НАСТРОЙКЕ» во время критических анализов и сессий QA, стал частью процесса проектирования Spotify. 13
Чтобы убедиться, что ваши принципы обладают вышеуказанными качествами, требуется время, самоотдача и командная работа Но это стоит усилий - основной набор принципов лежит в основе любой системы проектирования.
Выразить свой подход к дизайну в пяти предложениях нелегко. Каждая команда приходит к своим принципам по-своему: некоторые проходят раунды семинаров, другие могут получить информацию от своего генерального директора или креативного директора. Независимо от того, как вы туда доберетесь, вам могут быть полезны следующие советы.
Принципы дизайна должны поддерживать более широкую цель продукта и помогать выражать дух продукта. Если вы не знаете, с чего начать, посмотрите сначала на общие ценности вашей компании или видение продукта, а затем попытайтесь выяснить, как принципы дизайна могут способствовать достижению этой более широкой цели.
Основная цель веб-сайта TED может быть отражена в одном предложении: «Распространять идеи как можно шире и шире». С точки зрения этики и ценностей TED, это означает охват как можно большего числа людей, снижение барьера для входа, и сделать продукт инклюзивным и доступным. Это означает приоритезацию производительности и доступности по ярким функциям, ясность сообщения по смелому экспериментальному дизайну. Их принцип «безвременья» охватывает это.
Если вы все еще находитесь в процессе определения своих принципов, полезное упражнение - попросить нескольких членов команды (или каждого, в зависимости от размера команды) записать их индивидуально. Что, по их мнению, означает хороший дизайн для вашего продукта? Как бы они объяснили это в пяти предложениях новому члену команды так, чтобы это было практично и легко понять?
Попросите их найти практический пример в интерфейсе вашего продукта и включить его в каждый принцип.
Сравнение ответов вашей команды может показать, насколько вы едины в подходе к дизайну. Много ли общих тем и совпадений? Разные дисциплины заканчивались схожими принципами? Всегда интересно видеть ответы каждого, в частности, как они различаются между людьми, которые только что присоединились к команде, и теми, кто работал над продуктом в течение некоторого времени. Эти ответы могут стать ценной отправной точкой в дальнейшей работе над принципами, поскольку вы определяете общие темы и соглашаетесь с приоритетами.
Безошибочный способ придумать расплывчатые принципы дизайна - не знать, для кого они. Вы пишете для брошюры фирменного стиля? Для сайта компании? Сайт карьеры? Потенциальные партнеры и клиенты? Попробуйте написать свои принципы для себя и своих коллег, в первую очередь: дизайнеров, разработчиков, производителей контента, специалистов по маркетингу, экспертов по предметной области - людей, непосредственно вовлеченных в создание продукта. Постарайтесь найти неформальное соглашение о том, что является хорошим дизайном для вашего продукта, и предложите практические рекомендации для его достижения.
По мере развития вашего продукта будут развиваться и ваши принципы. Они будут формировать язык дизайна, который, в свою очередь, будет формировать принципы. Или они могли бы начать быть ясными и сфокусированными, но со временем становятся более размытыми и теряют свою подлинность. Чтобы принципы вашего дизайна продолжали совершенствоваться, их необходимо постоянно тестировать, оценивать и совершенствовать. Это можно сделать, только осознавая их и применяя их в своей работе каждый день. Например, делая свои принципы частью критического анализа проекта, вы можете непрерывно проверять, помогают ли они в процессе проектирования, а если нет, продолжать их повторять.
Одна из трудностей, с которыми я столкнулся в своей работе в качестве дизайнера, заключается в том, чтобы решить, как материализовать концепции более высокого уровня, такие как принципы дизайна и ценности бренда, в конкретные элементы пользовательского интерфейса. Как именно они воплощены в шаблонах дизайна, которые мы создаем?
Многое связано с выбором и исполнением шаблонов. Для Medium на функциональном уровне требовался текстовый редактор. Это мог быть редактор любого типа, любой сложности. Но из всех возможностей Medium выбрал самый простой, руководствуясь принципом «Направление над выбором».
Для TED ясность сообщения важнее эстетики. Попытка разделить речь в одном предложении может быть трудной, а иногда заголовки могут быть длинными. Было бы легче обрезать заголовок, но для команды сообщение разговора всегда должно иметь приоритет. Вместо того чтобы выбирать более простое решение, они следят за тем, чтобы их шаблоны проектирования могли вместить длинные названия.
Шаблон баннера героя на экране TED.com может вместить длинные заголовки, что соответствует их принципам дизайна.
С точки зрения бренда, существует чувство приоритета. Например, команда TED решила не вводить новую домашнюю страницу с изображениями, пока не разработала инструмент сжатия, чтобы минимизировать влияние таких изображений на производительность.
Для команды Atlassian «оптимистический» принцип воплощен в « оптимистическом интерфейсе» . 14 »В JIRA, например, когда пользователь должен переместить карту с« В процессе »на« Готово », карты могут быть перемещены сразу, обеспечивая мгновенный ответ пользователю, даже если в фоновом режиме есть много проверок и проверок, и много вещей, которые могут пойти не так. Они нацелены на то, чтобы выразить принцип «практично с подмигиванием» через дружественный язык копии, сообщений обратной связи, регистрации и других местах по всему сайту.
Шаблоны дизайна основаны на основной идее того, как работает продукт. Подумайте о том, как воплощение «прозрачности и сотрудничества» воплощается в открытых каналах Slack; как идея «запечатлеть уникальные моменты жизни» превращается в фотостудию и взаимодействия в Instagram; или как карты в Trello (функциональность, которая восходит к оригинальной системе HyperCard) стимулируют определенный тип рабочего процесса.
На выбор и исполнение шаблонов и их уникальную комбинацию влияют цель продукта, дух и принципы дизайна. Вы можете рассматривать принципы проектирования как грамматические правила для создания шаблонов и их сочетания способами, которые имеют внутренний смысл. Точно так же, по мере того как бренд и функциональные модели развиваются и становятся все более изысканными, они формируют принципы дизайна. Принципы и модели постоянно совершенствуются и находятся под влиянием друг друга.
В следующих двух главах мы поговорим о шаблонах проектирования более подробно, взяв за основу реальные продукты. Мы увидим, как возникают шаблоны проектирования и как на них влияют цель и характер продукта, поведение пользователей, бренд, бизнес-требования и другие факторы.
-
1. http://smashed.by/pinterestredesign
2. http://smashed.by/govukprinciples
3. « Итак… Что я делаю? ”Дэн Молл
4. « Когда дело доходит до виски, Америка знает Джека » Ави Дан
5. Google обладает хорошо известными общими принципами дизайна, такими как «Ориентация на пользователя, и все остальное будет следовать», и более конкретный набор принципов для своего языка дизайна материалов, например, «Движение обеспечивает смысл».
6. Пример адаптирован из принципов дизайна Pinterest в разделе « Редизайн Pinterest, блок за блоком ».
7. Пример адаптирован из принципа проектирования GDS .
8. Этот момент был вдохновлен прекрасной статьей « Дело принципа » Джули Чжуо.
9. http://smashed.by/lightning
10. « Создание полезных принципов дизайна » Дастин Сенос
11. http://smashed.by/researchingsystems
12. Для дальнейшего изучения ограничений человеческой рабочей памяти см. « Волшебная тайна четыре: как ограничена емкость рабочей памяти и почему? Нельсон Коуэн.
13. Стэнли Вуд « Дизайн не масштабируется »
В этой главе мы обсудим роль функциональных шаблонов и то, почему они должны быть определены в начале процесса проектирования.
Функциональные паттерны являются материальными строительными блоками интерфейса. Их цель состоит в том, чтобы включить или поощрить определенное поведение пользователей.
На десятиминутной кулинарной площадке некоторые из этих действий включали выбор ингредиентов, выбор рецепта и выполнение следующих шагов в течение выделенного времени. Функциональные шаблоны, которые мы разрабатываем, будут проинформированы об этом поведении Функциональные шаблоны, или модули 1 , в значительной степени определяются областью, к которой относится продукт. Шаблоны в нашем кулинарном приложении будут сильно отличаться, скажем, от финансового программного обеспечения. Вместо карточек с рецептами мы будем иметь дело с панелями задач, полями данных, сетками, диаграммами и графиками.
Функциональные шаблоны могут быть простыми или объединяться для создания более сложных шаблонов. Карта рецепта состоит из названия еды, изображения, ингредиентов и кнопки действия. У каждого модуля в карточке рецепта есть своя цель: название говорит нам, что такое еда; изображение обеспечивает предварительный просмотр окончательного результата; Значки ингредиентов позволяют нам легче сканировать карты. Вместе эти модули помогают достичь общей цели: побудить людей готовить еду, показанную в рецепте.
Как продукт развивается, так и шаблоны. Мы можем начать разрешать нашим пользователям оценивать рецепты, и отображение рейтинга станет частью карты рецептов. Или мы можем решить, что макет карты можно улучшить, или что значки ингредиентов должны быть более понятными, или что нам нужно представить компактную версию карты. Мы проверяем и повторяем шаблоны, чтобы заставить их работать лучше для достижения своей цели; то есть, поощрение поведения более эффективно.
Изучение назначения шаблонов на ранних этапах процесса проектирования может помочь предотвратить дублирование по мере роста продукта. Поначалу может показаться, что оно того не стоит. в конце концов, продукт может меняться слишком быстро в первые дни, чтобы иметь возможность определить все части интерфейса. Но действительно ли основные функциональные паттерны так сильно меняются? Давайте возьмем FutureLearn в качестве примера и посмотрим, как развивался интерфейс за три года, прошедшие с момента первоначального проектирования.
С тех пор как FutureLearn был основан Открытым университетом в 2013 году, его цель заключалась в том, чтобы «вдохновлять всех учиться рассказывать истории, провоцировать беседы и праздновать прогресс». Чтобы сделать это, как минимум, мы должны были убедиться, что люди смогут откройте для себя онлайн-курс и присоединитесь к нему, мотивируйте его на продвижение и сделайте учебный процесс полезным и стимулирующим. Это видение послужило основой для начальных функциональных паттернов FutureLearn.
Курсы расположены в единицах, и к ним есть линейный поток - одна часть ведет к другой. На уровне интерфейса это переводится в недельную структуру. Каждая неделя разбита на действия, а действия на шаги. Модуль прогресса курса является одним из основных функциональных шаблонов: он позволяет учащимся ориентироваться в содержании курса, показывает его прогресс и место, где курс в настоящее время активен.
Модуль прогресса курса на FutureLearn.
Эти шаблоны претерпели некоторые изменения после того, как были впервые разработаны более трех лет назад. Их стили и даже функциональность и взаимодействие изменились. Тем не менее, их цель в основном осталась прежней, поскольку она связана с основной идеей того, как работает FutureLearn.
Страница дел в течение трех лет подверглась нескольким изменениям, но цель основных модулей осталась прежней.
Точно так же дискуссионные темы по FutureLearn со временем развивались, так как количество участвующих людей увеличилось: изменилось расположение потоков, взаимодействий и функций фильтрации, но их основная цель остается в значительной степени той же - вовлекать учащихся в беседу и позволяют им учиться друг у друга.
Страницы обсуждения прошли несколько итераций после их разработки, но назначение основных модулей не изменилось.
Базовый блок для отображения сведений о курсе также развивался в течение трех лет, чтобы пользователи могли видеть больший выбор списков курсов перед тем, как прокрутить страницу вниз. Но опять же, цель шаблона остается той же - позволить людям открывать и присоединяться к интересующим их курсам.
Список курсов развивался годами, чтобы пользователи могли видеть больший выбор списков курсов.
Как часто случается в первые дни запуска, из-за временных ограничений и других приоритетов многие основные функциональные модели не были определены. По мере роста интерфейса и образовательной функциональности FutureLearn шаблоны дублировались. Мы закончили с несколькими модулями прогресса курса, вариантами модуля комментариев и несколькими различными блоками курса и карточками курса по всему сайту. Возможно, это было неизбежно. Или некоторые из этих дубликатов могли быть предотвращены?
Когда шаблон не определен и не передан в команду, вы начинаете воссоздание его для достижения аналогичных целей: другой рекламный модуль, другой канал новостей, другой набор ссылок для обмена, еще один раскрывающийся список. Прежде чем вы это узнаете, у вас будет 30 различных продуктов и всплывающие меню.
Шаблоны - это физическое воплощение поведения, которое мы пытаемся поощрить или включить через интерфейс. Их исполнение, содержание, взаимодействие и представление могут измениться. (На самом деле шаблоны даже не должны быть визуальными - они могут быть прочитаны голосом или воплощены иным образом.) Но основные модели поведения, которые они призваны поддерживать, остаются относительно стабильными, поскольку они вытекают из цели вашего продукта и идея о том, как он работает. Осознание цели ваших ключевых шаблонов может помочь вам понять, как работает ваша система и предотвратить ее фрагментацию по мере развития.
Определение шаблонов на ранних этапах процесса проектирования не должно занимать много времени. Есть методы, которые могут быть интегрированы в ваш процесс без лишних усилий. Вот некоторые из них, которые я считаю особенно полезными.
Чтобы наметить потребности, цели и мотивацию ваших клиентов, вы могли бы составить карту взаимодействия с клиентами 2 , «работа будет выполнена» 3или аналогичное упражнение в поездках клиентов. Результаты, как правило, учитываются в ранних исследованиях дизайна и прототипов. На этом этапе обычно есть достаточно четкое понимание поведения, которое мы хотим поощрить или включить в наших пользователях: узнать о курсе, присоединиться к курсу, участвовать в обсуждении. Но как только мы фокусируемся на интерфейсе, иногда мы теряемся в деталях. Мы тратим время на создание самого впечатляющего заголовка страницы, забывая, для чего этот заголовок и как он влияет на пользователя в разных частях их пути. Другими словами, мы теряем связь между поведением пользователей и точными шаблонами, которые поощряют или разрешают такое поведение.
Чтобы увидеть, как ваши шаблоны вписываются в общую картину, попробуйте сопоставить некоторые из ваших основных модулей с разделами пользовательского путешествия. Подумайте, для чего предназначен каждый раздел и какое поведение он призван поощрять. Вам не нужно беспокоиться о захвате каждого значка или кнопки на этом этапе. Сосредоточьтесь на общей картине: поймите части системы и как они работают вместе. Для FutureLearn он был в основном сфокусирован на трех областях: поиск контента, обучение на курсе и достижение цели.
Некоторые из функциональных шаблонов FutureLearn сопоставлены с тремя ключевыми этапами пользовательского пути.
Хранение этой карты в моей памяти помогло мне подумать о семействах шаблонов, объединенных общей целью , а не отдельных страницах. Например, вместо того, чтобы создавать страницу со списком курсов, я бы подумал об области «Открытие» в целом. Какое поведение мы должны поощрять на этом этапе путешествия пользователя? Какие модели могут поддерживать такое поведение? Где еще на сайте они существуют и как они там работают? Если это новый шаблон, как он влияет на всю систему? Размышление над всеми этими вопросами является частью систематического проектирования.
Процесс инвентаризации интерфейса 4 , описанный Брэдом Фростом, стал популярным способом начать модульность интерфейса. Идея проста. Вы распечатываете экраны вашего интерфейса на бумаге или собираете их в Keynote или PowerPoint. Затем вы выделяете различные компоненты, вырезая их или вставляя их в Keynote.
Инвентаризация интерфейса, показывающая некоторые из интерактивных элементов.
В итоге вы получите набор деталей, которые можно сгруппировать по категориям: навигация, формы, вкладки, кнопки, списки и т. Д. Пройдя этот процесс, вы сможете увидеть дублированные шаблоны и выявить проблемные области, требующие внимания. Это когда вы обнаружите, что у вас есть десятки заголовков или всплывающих меню, и начинаете думать о том, как навести порядок во всем этом.
Инвентарь не должен охватывать все (хотя самый первый, который вы делаете, должен быть всеобъемлющим). Он может фокусироваться на одной группе шаблонов за раз, такой как рекламные модули, заголовки или все модули отображения продукта. Вы можете сделать инвентарь, ориентированный конкретно на типографику, цвет или анимацию.
Для большей эффективности инвентаризации интерфейса следует проводить регулярно. Даже если ваша команда поддерживает библиотеку шаблонов, появятся новые шаблоны, которые необходимо сложить в систему. Если у вас появляется привычка проводить инвентаризацию каждые несколько месяцев, каждый раз это не должно занимать более пары часов. И каждый раз, когда вы делаете это, вы лучше понимаете свою систему и можете ее улучшить. 5
Для того, чтобы понять цель шаблон, сосредоточьтесь на том, что он делает , а не то , что вы думаете , что это . Другими словами, попытайтесь найти действие, которое лучше всего описывает поведение, для которого предназначен шаблон. Описание шаблона с глаголом, а не с существительным, может помочь вам расширить потенциальные варианты использования шаблона и более точно определить его назначение.
Допустим, вы ввели простой модуль для продвижения онлайн-курса. Если вы попытаетесь описать, что это такое, вы можете назвать его «Заголовок изображения» или «Баннер курса».
Компонент пользовательского интерфейса, продвигающий онлайн-курс по FutureLearn.
Но, описывая шаблон таким образом, вы можете сделать его слишком специфичным для его представления или содержания. Вы можете ограничить его использование определенным контекстом. С другой стороны, если вы определите его с точки зрения действий - как с точки зрения вашего пользователя, так и с точки зрения вашего собственного - вы сможете раскрыть его цель: « Продвигать курс» и « Узнать курс»; и « Вдохновляйтесь присоединением к курсу» и « Поощряйте людей к участию». Сосредоточившись на действии, вы связываете шаблон с поведением и оставляете его открытым для различных вариантов использования. Что еще может продвигать этот шаблон? Онлайн обсуждение? Новое событие? Имя, которое вы даете, должно также отражать это. В приведенном выше примере мы назвали модуль «Рекламный щит», чтобы отразить его ориентированную на действие рекламную функцию.
Чтобы получить общее представление о том, как работает шаблон, нарисуйте его структуру: основные типы контента, который должен быть эффективен для модуля.
Дизайнеры, разработчики и контент-стратеги могут делать это вместе при работе над новым модулем или при рефакторинге существующего. Начните с перечисления основных элементов контента, который должен быть эффективен для модуля. Например, вы можете согласиться с тем, что в вашем интерфейсе рекламный модуль типа «Билборд» нуждается в:
• заголовок
• сильный призыв к действию
• привлекательный фон (сплошной цвет или изображение)
Затем попытайтесь определить иерархию элементов и решить, как они должны быть сгруппированы; например: является ли изображение частью контента? Всегда ли необходим ярлык? Делая это, сделайте несколько набросков, чтобы визуализировать структуру. Чтобы дать вам представление о том, как это может выглядеть, вот пример структуры контента для модуля элемента списка курсов в FutureLearn.
Пример структуры контента для элемента списка курсов на FutureLearn.
В этот момент вы можете подумать: «Это просто набросок или каркас. В любом случае, я все время так делаю ». Но это немного по-другому. Это эскиз, сфокусированный конкретно на структуре содержимого модуля, а также на иерархии и группировке элементов.
Если у вас есть общее представление о структуре шаблона, легче убедиться, что способ разработки модуля отражен в разметке. Дизайнер может работать над визуальными исследованиями, а разработчик может начать собирать прототип (или оба могут создавать прототипы, в зависимости от того, как вы работаете). Дизайнеры понимают, насколько они могут визуально протолкнуть шаблон, прежде чем он станет чем-то другим. Разработчики знают причины выбора дизайна и не бросают неожиданные проекты им за стену. Каждый знает, как устроен шаблон и как его изменение повлияет на другие места.
Вот еще один пример. На FutureLearn у нас было четыре разных версии социальной сети в разных областях сайта - две версии «Комментарий», «Ответ» и «Уведомление».
Четыре различных версии модулей социальных сетей на FutureLearn.
Хотя на первый взгляд они выглядели одинаково, у них не было одинаковых стилей; то есть, если вы изменили один из них, изменения не будут применяться к другим, были визуальные несоответствия в интервале и типографии, и так далее.
Разбивая их и рисуя их структуры, мы увидели, могут ли они быть объединены в один шаблон, и спроектировали этот шаблон так, чтобы он работал во всех четырех случаях использования. 6
Структура контента для модуля «Лента новостей» в FutureLearn.
Структура контента тесно связана с назначением шаблона, как показали эти примеры. Знание того, как структурирован модуль, помогает нам понять, как он работает.
Попробуйте разместить похожие шаблоны в масштабе по отношению друг к другу. Например, в вашей системе может быть несколько рекламных шаблонов с различной степенью интенсивности. Как и в шкале визуальной громкости 7, о которой я упоминал в главе 1, рекламные модули можно сравнивать друг с другом.
Рекламные модули могут быть размещены на воображаемой шкале визуальной громкости.
Размещение шаблонов в масштабе может помочь убедиться, что они используются надлежащим образом и не конкурируют за внимание всей системы. Это также помогает предотвратить ненужное воссоздание модулей, поскольку вы можете видеть, когда у вас уже есть модуль на том же «томе».
Еще один способ думать об этом - представить, что ваш интерфейс не визуальный, а голосовой. Когда этот голос должен был стать громче и изменить интонацию? Подумайте о том, как этот объем и интонация могут быть выражены визуально, через отношения между элементами в модулях, а также их иерархию в общем дизайне. Размышление об этом таким образом, конечно, также имеет дополнительное преимущество, делающее его более доступным для программ чтения с экрана.
Вот парадокс. Предполагается, что мы спроектируем контент в первую очередь, но в то же время мы должны создавать модули таким образом, чтобы они подходили для любого вида контента. Способ сделать это не обязательно, начиная с контента, но с цели. Тогда мы можем рассматривать контент не как известный актив, а как гипотезу . Это позволяет нам проверить, правильно ли мы определили назначение модуля и работает ли дизайн для этой цели.
Предположим, у нас есть модуль, который был разработан для отображения характеристик продукта.
Пример модуля, предназначенного для представления характеристик продукта.
Мы можем определить его назначение как «Поддержка основного сообщения дополнительными битами легко сканируемой информации». «Битами» могут быть ключевые функции, короткие советы или быстрые шаги. Мы можем создать шаблон для контента, который соответствует этой гипотезе (краткий и сканируемый, дополнительный, а не основной контент на странице), а затем протестировать его.
Если содержимое постоянно оказывается неподходящим для этого шаблона, оно обычно вызывается одной (или несколькими) из этих трех причин:
• Мы не правильно определили цель шаблона. Вернитесь к попыткам понять поведение, для которого оно было разработано.
• Мы не спроектировали шаблон таким образом, чтобы наилучшим образом достичь его цели. Попробуйте другой дизайн для этого шаблона.
• Мы пытаемся заставить контент в шаблон, который не совсем подходит для него. Попробуйте пересмотреть содержимое или попробуйте другой шаблон.
Когда мы не начинаем с цели и структуры, мы можем получить модули, которые слишком тесно связаны с их содержанием. Например, у нас был случай на FutureLearn, когда копия нажимала важные вкладки ниже видимой области.
Пример хрупкого модуля, который был слишком специфичен для его содержимого.
Вкладки должны были оставаться видимыми. Чтобы обойти проблему, мы почти ввели специальный заголовок меньшего размера, просто чтобы немного подтолкнуть вкладки. Но если бы мы сделали это, мы бы получили модуль, который не был надежным. Если заголовок станет длиннее или мы добавим дополнительную строку, мы застряли бы с той же проблемой. Если бы мы начали с цели модуля и его структуры, вкладки, вероятно, были бы размещены сверху, поскольку они являются таким важным элементом дизайна.
Это лишь некоторые из инструментов и методов, которые вы можете попробовать определить функциональные шаблоны в вашем интерфейсе. Самое главное, чтобы понять, как шаблоны связаны с поведением, для которого они были изначально разработаны: их цель.
Цель определяет все остальное: структуру паттерна, его содержание, представление. Знание цели шаблона (знание того, какое поведение он предназначен для поощрения или включения) может помочь нам спроектировать и построить более надежные модули. Это может помочь нам узнать, насколько шаблон может быть изменен, прежде чем он станет чем-то совершенно другим. И это может уменьшить дублирование, предоставляя всей команде общую точку отсчета и соединяя их с первоначальным замыслом дизайна. Понятность цели также облегчает тестирование шаблонов, чтобы увидеть, насколько они эффективны.
Если функциональные шаблоны являются объектами в интерфейсе, тогда шаблоны восприятия больше похожи на стили - они описывают, что это за объекты и как они себя чувствуют. Давайте внимательнее посмотрим на них.
-
1. Если бы нам пришлось проводить различие между ними, я вижу функциональные шаблоны в более общем виде, как своего рода платоновский идеал, а модули - как воплощение функциональных шаблонов, которые могут различаться в разных интерфейсах.
2. http://smashed.by/mappingxp
3. « Работа, которую нужно выполнить » (JTBD) - это упражнение, которое помогает вам сосредоточиться на основной мотивации использования продукта или услуги, а не на самом продукте. Например, даже если клиенты говорят, что они покупают газонокосилку, чтобы «подстригать траву», их более высокая цель может заключаться в том, чтобы «держать траву низкой и красивой всегда», что может указывать на то, что газонокосилка не является подходящим инструментом для работы. на первом месте.
4. http://smashed.by/uiinventory
5. В главах 7 и 8 мы подробно рассмотрим процесс инвентаризации интерфейса, начиная с цели системы и заканчивая мельчайшими шаблонами, такими как значки и цвета.
6. В главе 8 мы обсудим более подробно, когда объединять шаблоны, когда их разбивать, а когда создавать варианты.
В этой главе мы обсудим, как работают шаблоны восприятия и их роль в системе проектирования.
Представьте, что у нас обоих есть дом с одинаковым набором мебели: стол, несколько стульев, кровать и шкаф. Даже при том, что мебель одинакова, наши дома могут чувствовать себя совершенно по-другому: это может быть из-за стиля мебели, материалов, цветов, фактур, ткани на покрывалах, стиля орнаментов, того, как мы планируем комната, освещение или даже музыка, которую мы играем внутри. Я имею в виду такие атрибуты как модели восприятия . Из-за них ваш дом может выглядеть как богемное логово, а мой - как склад. 1
Примеры шаблонов восприятия в цифровых продуктах включают тон голоса, типографику, цветовую палитру, макеты, иллюстрации и стили значков, формы и текстуры, интервалы, изображения, взаимодействия или анимацию, а также все конкретные способы объединения и использования этих элементов в интерфейс. Образцы восприятия присутствуют всегда, даже если они не предназначены специально. Даже чисто функциональный инструмент имеет эстетическое значение.
Иногда такие качества воспринимаются как укладка или кожа продукта - слой сверху. Но чтобы быть эффективными, они должны жить не только на поверхности, но и в основе бренда , и они должны развиваться вместе с продуктом. Когда эффективные, модели восприятия становятся мощными дифференциаторами продукта.
Продукты могут отличаться, даже если они принадлежат одному домену и имеют похожие модули. Чтобы написать эту книгу, я попробовал десятки текстовых процессоров с очень похожим функционалом. Только у нескольких из них, включая ту, которую я сейчас использую, была такая среда письма, которая помогла мне сосредоточиться и быть наиболее продуктивной. 2 Я могу описать его как четкое и спокойное, демонстрируя эстетику без отвлечения внимания с акцентом на важные вещи, такие как отображение контура документа или маленькие кружки, которые становятся зелеными, когда я подхожу к своей «цели письма». Эта среда создается с помощью комбинации определенных шаблонов, хотя на первый взгляд нелегко определить, что они из себя представляют.
Давайте возьмем другой пример: Spotify. Для меня это тепло и личное. Какие именно шаблоны создают атмосферу близости в этом интерфейсе службы цифровой музыки с более чем 100 миллионами пользователей в месяц? Помимо функциональности, это в значительной степени обусловлено стилями изображений, сочетаниями цветов (особенно соотношением зеленого и черного), тонким и спокойным ощущением взаимодействия и выбором типографики. 3
Атмосфера близости в Spotify является результатом сочетания моделей восприятия, таких как тонкие взаимодействия, приглушенные образы и цветовые акценты.
С другой стороны, игривый, творческий, откровенно восторженный и слегка необычный персонаж журнала Smashing Magazine передается через другой набор шаблонов - от смелой цветовой палитры и иллюстраций, вплоть до мельчайших деталей, таких как небольшой угол на некоторых элементы интерфейса.
Характер Smashing Magazine передается через различные модели восприятия - от типографских обработок до игривого угла изображений и значков.
Шаблоны восприятия выражают бренд через интерфейс и помогают сделать его запоминающимся. Посмотрите на изображения ниже: можете ли вы узнать, какие продукты они представляют?
Можете ли вы узнать, какие продукты представляют эти два изображения?
На этих изображениях не так много информации: стили оформления, некоторые формы и цвета и несколько значков. Но эти визуальные подсказки настолько различны, что вы все еще могли бы распознать, к каким продуктам они относятся (Slack и TED). Целенаправленно и многократно применяя их, они формируют шаблоны, поэтому мы можем их вызывать и ассоциировать, даже если эти шаблоны появляются вне контекста.
На восприятие влияют не только строительные блоки, такие как цветовая палитра и шрифт, но и отношения между ними. Недостаточно последовательно использовать заголовки и цвета в модулях. Мы также должны знать об уникальных пропорциях и комбинациях, которые заставляют продукт чувствовать себя определенным образом. Как цвета связаны друг с другом? Как образы связаны с типографикой? Как типография связана с интервалом?
Майкл МакВаттерс, архитектор UX в TED, в интервью поделился тем, как важно для бренда TED, чтобы красный цвет отображался в правильных пропорциях: «Красный должен использоваться с осторожностью и продуманно. Используйте его не в тех местах или слишком часто, и это больше не похоже на TED ».
В модульных системах достижение визуальной согласованности и цельности может быть непростым делом. Модули создаются разными людьми для разных целей. Поскольку шаблоны восприятия проникают через разные части в системе, они соединяют эти части. Когда соединения эффективны, пользователи чувствуют единство, которое связывает модули вместе.
Посмотрите, как Vox и Guardian применяют шаблоны восприятия, чтобы объединить различные элементы, объединяя их в единое целое. В Vox привлекательные образы с большими заголовками, четкие сочетания шрифтов и щедрое белое пространство объединяются, чтобы передать ощущение образа жизни журнала под знаменем Vox - он просторный, неформальный и, возможно, даже немного бунтарский. Напротив, типография, интервалы, образы и цвета в «Гардиане» создают более плотное, более достоверное ощущение, более подходящее для источника серьезной журналистики и мнений. 4
Соединения могут быть сделаны не только между модулями, но и между различными платформами и контекстами. Специфичные для платформы стандарты, такие как проектирование материалов, дают достаточно авторитетное представление о том, как следует разрабатывать и создавать шаблоны. Когда компании строго следуют стандартным соглашениям о платформах, они очень полагаются на шаблоны восприятия, чтобы продукт чувствовал себя частью одного бренда.
Иногда самые маленькие вещи могут помочь установить связь. Несмотря на то, что между приложениями Twitter для веб-сайтов, нативными и сторонними платформами есть различия, мелкие детали, такие как «сердечная» реакция «Мне нравится», помогают распространять язык шаблонов Twitter.
Кадр из сердечной анимации Twitter, представленный в 2015 году на Twitter для iOS, в Интернете, Android, TweetDeck, Twitter для Windows 10 и других платформах.
Если функциональные модули отражают то, что пользователи хотят и нуждаются, тогда шаблоны восприятия фокусируются на том, что они чувствуют или делают интуитивно. Вместо того, чтобы исходить из поведения и действий пользователей, на них влияет индивидуальность или атмосфера, к которой стремится продукт.
В « Designing for Emotion 5» Ааррон Уолтер предлагает, как простым способом команды могут уловить ключевые личностные качества, создавая «дизайнерскую личность», которая воплощает черты, которые они хотят включить в ваш бренд. Уолтер рекомендует основывать личность на реальном образе человека, чтобы он казался менее абстрактным. Если это трудно, я иногда нахожу полезным подумать о месте и его окружении, а не о чьих-то чертах личности. Например, что такое атмосфера, которая подходит для сфокусированного письма, в отличие от непринужденной социальной болтовни?
Независимо от того, используете ли вы человека или место в качестве отправной точки, цель состоит в том, чтобы получить несколько (Уолтер рекомендует около пяти-семи) черт, которые лучше всего описывают ваш бренд, а также черт, которых следует избегать. Для MailChimp эти черты включают «Весёлый, но не детский». Смешно, но не глупо. Мощный, но не сложный. Бедро, но не отталкивает. Неформальный, но не неряшливый » 6.
Затем команды могут определить способы воплощения этих черт в жизнь через интерфейс: тон голоса, визуально и другими способами, такими как взаимодействия и звуки. Для MailChimp некоторые из шаблонов визуального восприятия (или «визуального словаря», как об этом говорит Уолтер) включали яркую, но слегка ненасыщенную цветовую палитру, простую типографику без засечек и плоские элементы интерфейса с мягкими, тонкими текстурами в некоторых местах, чтобы согреть пространство.
Вот некоторые из популярных методов проектирования, которые могут помочь исследовать шаблоны восприятия.
Доски настроения - отличный инструмент для изучения различных визуальных тем. Их можно создавать в цифровом виде ( Pinterest 7 - популярный инструмент для создания цифровых досок для настроения) или собирать физически на большой доске, используя вырезки из журналов и другого печатного материала.
Некоторые люди используют доски настроения, чтобы исследовать текущие тенденции или собирать идеи, в то время как другие генерируют их, чтобы понять, как может выглядеть их бренд. Доски настроения могут быть широкими, или они могут фокусироваться на изучении определенных частей бренда, таких как цвет или типографика.
Пример доски настроения, которая исследует цвет и градиенты.
После определения общего направления бренда стилевые плитки могут быть полезны для более детального изучения нескольких вариантов. Концепция стилей плиток была представлена Самантой Уоррен 8 , которая описывает их как «готовый дизайн, состоящий из шрифтов, цветов и элементов интерфейса, которые передают сущность визуального бренда для Интернета» 9.
Сайт кампании Washington Examiner 2012.
Как и доски с настроением, плитки стиля могут предоставить ценную дискуссию пользователям и заинтересованным сторонам, а также оценить их первоначальную реакцию на конкретные направления дизайна. Сравнение и контрастирование стилей плитки друг против друга может помочь вам сделать выбор одного направления по сравнению с другим.
Обращаясь к стилю плиток, Dan Mall 10 предложил идею коллажа элементов: сборки элементов интерфейса, которые исследуют, как работает брендинг в интерфейсе. Как дизайн, они могут чувствовать себя более конкретными и ощутимыми, чем стиль плитки; тем не менее, коллажи элементов не имеют столько ожиданий, сколько полные визуальные макеты. Элементные коллажи исследуют не только общее направление бренда, но и то, как бренд выражается через интерфейс.
Элемент коллажа для РИФа.
Различия между этими методами не всегда очевидны, и люди используют их взаимозаменяемо. Для меня различие заключается в их относительной верности. Настроения настроения более свободные и более открытые; они объединяют существующие материалы из различных источников, чтобы создать определенное визуальное ощущение. Стиль плиток и элементов коллажей больше ориентирован на конкретный продукт и практическое применение шаблонов в интерфейсе. Коллажи элементов обеспечивают высочайший уровень точности и могут быть использованы в качестве отправной точки для перехода к полноценным композициям.
Процесс развития стилей продолжается, когда они интегрированы в продукт. Испытание бренда в более реалистичной обстановке интерфейса с модулями и взаимодействиями часто приводит к уточнению как перцептивных, так и функциональных паттернов. Обычно это итеративный процесс, в котором шаблоны влияют друг на друга до тех пор, пока язык проектирования не начнет формироваться.
Давайте посмотрим, как разрабатывались стили FutureLearn. На изображении ниже показаны первые исследования Вольфа Олинса 11 для бренда FutureLearn. В то время как они фиксируют часть личности, которую пытался спроецировать FutureLearn (минимальный, смелый, яркий, позитивный, праздничный), существует разница между первоначальным направлением и тем, как оно развивалось с течением времени.
Первоначальные исследования бренда для FutureLearn.
Вот как выглядели основные шаблоны восприятия спустя несколько месяцев после того, как визуальные эффекты были переданы внутренней команде разработчиков в FutureLearn:
Элемент коллажа для FutureLearn.
Применяя их к фактическому контексту, в котором они собирались жить, модели должны были стать более обоснованными, более конкретными и более практичными. Вот как иконография FutureLearn превратилась из первоначальных концепций в дизайн, который вы можете увидеть на сайте сегодня:
Первоначальный дизайн иконок Вольфа Олинса (слева) и как они развивались командой дизайнеров FutureLearn (справа). Пробелы в значках означают, что процесс обучения никогда не завершается.
На концептуальном этапе развития бренда было важно идти широко и масштабно, не заботясь о каждой детали. Но когда мы начали применять концепции, их нужно было доработать, чтобы они подходили для новой среды, которую они занимали. Акцент сместился с открытого исследования на уточнение и согласованность.
На данном этапе задача состоит в том, чтобы продолжать развивать бренд, сохраняя при этом закономерности. Как отметила Люси Блэквелл, креативный директор FutureLearn: «Когда вы полностью сосредоточены на согласованности, некоторые важные тонкости того, что заставляет продукт чувствовать определенный образ, могут быть потеряны».
Точно так же, как введение слишком большого числа исключений может ослабить бренд, слишком большое внимание к последовательности может также задушить его. Как это ни парадоксально, если сделать дизайн идеально согласованным, это не гарантирует, что он будет «на бренде». Иногда это может иметь обратный эффект - между последовательностью и однородностью есть тонкая грань.
С семью дизайнерами, работающими в нескольких потоках, в FutureLearn нам пришлось настроить процессы, которые позволили нам сосредоточиться на повторном использовании и полезности. Но в некоторых областях сайта мы слишком внимательно следили за ними, иногда за счет ослабления бренда. Вот как страница курсов изменилась с течением времени:
Страница курсов FutureLearn в 2015 году и в конце 2016 года.
Имело смысл сделать дизайн более практичным, чистым и организованным. Это также было положительным изменением для SEO и метрик, и больше соответствовало другим страницам сайта. Но в то же время мы чувствовали, что при этом некоторые из визуальных особенностей, присутствовавших в начале, были потеряны. В то время как мы приняли это изменение в некоторых областях сайта, в других - особенно в маркетинговых кампаниях под брендом - мы начали больше экспериментировать, пытаясь сделать бренд более сильным.
Если система проектирования только отдает приоритет идеальной согласованности, она может стать общей и жесткой. Развивающиеся шаблоны восприятия требуют места за пределами системы, и дизайнеры должны активно поощряться к исследованию. Хорошая система дизайна обеспечивает баланс между последовательностью и креативным выражением бренда.
Шаблоны восприятия могут быть сосредоточены в мельчайших деталях. В своей книге « Microinteractions 12» Дэн Саффер ввел термин «характерные моменты» - небольшие взаимодействия, которые становятся отличительными чертами продукта, такие как «элегантная анимация загрузки» или броский звук («У вас есть почта!»). »Моменты подписи особенно сильны, когда имеют смысл или историю позади них. Например, тонкий эффект пульсации на кнопке воспроизведения TED был вдохновлен культовой анимацией вступления их видео.
Отбрасываемая анимация TED заставок их видео отражается в эффекте ряби на кнопке воспроизведения видео.
В цифровых продуктах моменты подписи не всегда рассматриваются как требование, и некоторые команды пытаются расставить приоритеты. 13 Но это мелкие детали, которые могут добавить дополнительный уровень глубины и значения для опыта. В наших усилиях по систематизации и структурированию дизайна важно осознавать детали, которые делают что-то особенным. В системе проектирования всегда должно быть пространство, чтобы развивать и развивать эти моменты.
Как мы можем сделать пространство для творческих исследований? И как мы тогда складываем новые стили в систему? В FutureLearn мы обнаружили, что наиболее эффективно было сначала поэкспериментировать в небольших масштабах. Если некоторые элементы работали хорошо, мы постепенно интегрировали бы их в другие части интерфейса.
Например, мы чувствовали, что у чисто функциональной кнопки переключения не было ощущения праздника и достижения, когда учащиеся выполнили шаг. Он был заменен круговым стилем, оживленной анимацией и всплывающей иконкой.
Оригинальная кнопка прогресса (слева) и измененная кнопка (справа) на FutureLearn.
В то время как новая кнопка получила положительные отзывы от наших учеников, она не чувствовала себя частью системы, пока мы не начали повторять круговой рисунок, оживленную анимацию и метки в других областях сайта. Без этих дополнений элемент чувствовал себя отключенным.
Иногда мы пробовали новые шаблоны в рекламных зонах, таких как домашняя страница или сайт кампании. Бренд FutureLearn использовал прежде всего квадратные формы. Во время редизайна домашней страницы мы представили шаблон треугольника. Он был усилен, когда другие дизайнеры начали применять его в других областях, таких как стили изображений и дизайн сертификатов.
Первоначальные эксперименты с треугольниками на домашней странице начались довольно плоско (слева), но другие дизайнеры дали новый поворот, взяв шаблон и применив его к своим проектам.
Экспериментируя с узорами треугольников, мы знали, что они находятся за пределами типичной квадратной эстетики FutureLearn, но хотели дать им попытку увидеть, что произойдет. Позже мы узнали, что, хотя треугольники работали с брендом, их нужно было экономно использовать только в качестве визуального улучшения в областях поиска и маркетинга сайта, а не на страницах с опытом обучения.
При изучении новых стилей, попробуйте их на небольшом участке сайта. Помните о том, что вы делаете по-другому, о шаблонах, которые находятся за пределами системы, и о причинах их применения. Если они работают, постепенно складывайте их в систему, применяя их в других областях сайта. Осознайте роль, которую они играют. Для FutureLearn треугольники используются для создания динамического эффекта; круги используются в качестве положительного подтверждения прогресса, как правило, в сочетании с галочкой.
Поскольку шаблоны восприятия иногда рассматриваются просто как стилизация или украшение, их изменение может быть менее спорным, чем, скажем, обновление потока взаимодействия. В результате, специальные бизнес-требования могут привести к появлению элементов, которые не соответствуют бренду. Например, мы хотели, чтобы наши ученики знали, когда начинаются новые курсы, поэтому мы добавили желтые баннеры к изображениям курсов.
Баннер «Только начался» на FutureLearn для освещения недавно начатых курсов.
Несмотря на то, что баннер не был идеально на бренде, это не было проблемой, так как в то время проводилось всего несколько курсов. Мы не знали, сколько еще курсов начнутся через несколько месяцев. Когда это произошло, баланс модуля курса сместился с ощущения основного момента к тому, чтобы казаться немного броским и ориентированным на продажи, чего мы стараемся избегать в бренде FutureLearn. Опять же, потому что это рассматривалось как часть стиля, было трудно расставить приоритеты и заняло много времени для решения.
Независимо от того, насколько мы охраняем бренд, такие вещи будут происходить - новые требования требуют нестандартных шаблонов и одноразовых настроек. Если мы не осознаем их, такие исключения могут ослабить или ослабить бренд.
Иногда даже небольшое изменение может изменить восприятие. В FutureLearn мы однажды почти заменили квадратные формы в модуле прогресса курса кругами, прежде чем заметили, что это полностью изменит ощущение интерфейса. Чтобы контролировать, как что-то чувствует, вам нужно понять точные шаблоны, которые влияют на это.
В вашей команде попробуйте выполнить быстрое упражнение. Попросите каждого человека написать наиболее четкие шаблоны восприятия для вашего продукта. Поощряйте людей смотреть за рамки строительных блоков, таких как цветовая палитра и шрифт, и вместо этого думать о принципах, комбинациях и методах высокого уровня, характерных для вашего бренда. Подумайте не только об элементах, но и об их значении - изображениях, которые они изображают, и историях, которые они рассказывают. В интерфейсе FutureLearn некоторые из этих шаблонов:
• Позитивный и обнадеживающий тон голоса
• В первую очередь белая цветовая палитра с розовыми акцентами
• щедрый пробел
• Как правило, большой размер шрифта с акцентом на удобочитаемость
• Высококонтрастная типография с пропорционально большими заголовками
• Яркий градиент от розового до голубого
• Розовое или голубое тонкое взаимодействие при наведении
• 1px светло-серые штрихи
• квадратные иконки размером 1 пиксель с «перерывом»
• В основном квадратные и иногда круглые формы, треугольники в рекламных зонах
Подобно упражнению с поиском общих тем в ваших принципах дизайна, описанным во второй главе, сравнение мыслей вашей команды может выявить различные способы восприятия вашего бренда. Поначалу качества могут быть расплывчатыми и нечеткими, но они являются отличной основой для дискуссий. Достижение общего понимания наиболее четких моделей восприятия является полезной отправной точкой для вашей будущей работы по их систематизации. 14
Шаблоны и принципы являются важной частью системы проектирования. Но, конечно, если вы работаете в команде, их недостаточно. Выбор слов и правил не делает язык. Он становится языком только тогда, когда вы приписываете значение этим словам, и другие люди начинают делиться этим значением.
-
1. Такое мышление может сделать посещение мест совершенно другим опытом. Будь то кафе, новый город или место для пикника, мне нравится думать о том, каково место, а затем попытаться определить некоторые из моделей, которые объединяются, чтобы создать эту атмосферу.
2. Это Улисс , на случай, если вы захотите узнать.
3. Видение Spotify «Правильная музыка для каждого момента» и принцип их дизайна «эмоциональный» соответствуют ощущениям, создаваемым посредством моделей восприятия.
4. Эти скриншоты были сделаны в марте 2017 года. Интересно, что пару недель спустя Vox изменил свой дизайн на более плотный, похожий на газету, чтобы выглядеть более «заслуживающим доверия и умным». См. « За обновлением домашней страницы Vox.com » для получения более подробной информации.
5. http://smashed.by/designingemotion
6. Дизайн для эмоций Ааррон Уолтер (см. Также « Личность в дизайне »)
11. http://www.wolffolins.com/
12. http://microinteractions.com/
13. За полезными практическими советами по проектированию микровзаимодействий и их интеграции в продукт, см. Микровзаимодействия: проектирование с деталями Дана Саффера.
14. В главе 9 мы поговорим о проведении инвентаризации интерфейса по шаблонам восприятия и интеграции их в систему.
В этой главе описывается, как установить общий язык, который позволяет группе людей связно создавать и использовать шаблоны для конкретного продукта.
Цифровые продукты создаются командами. У каждого будут свои конкретные цели и личные сроки. Это неизбежно означает, что будут добавлены неаккуратные шаблоны или что модули будут дублироваться или использоваться не по назначению.
Можем ли мы убедиться, что продукт по-прежнему ощущается сплоченным и цельным, даже когда над ним работает много людей? Да, если у нас есть общее понимание в команде, что такое наша система проектирования и как она работает. Это означает, что мы следуем тем же руководящим принципам, что наше видение бренда совпадает, что у нас общий подход к дизайну и интерфейсной архитектуре, и что мы знаем наши наиболее эффективные шаблоны и то, что заставляет их работать. Другими словами, создание систем единого дизайна требует общего языка .
В «Вневременном способе строительства» Кристофер Александер представил идею «языка шаблонов» как способа создания зданий, которые чувствуют себя живыми и доставляют удовольствие. В основе его книги лежит наблюдение о том, что многие великие здания (Шартр, Альгамбра (Купол Брунеллески) не была создана одним главным архитектором, который усердно работал над чертежной доской. Они были построены группами людей, которые все обладали глубокими общими знаниями о шаблонах проектирования, способных воплотить эти здания в жизнь.
«… Группы людей могут представить свои большие общественные здания на земле, следуя общему языку, почти как если бы у них был единый разум»,
- Кристофер Александр, Вневременный путь строительства
Аналогичная идея может быть применена к созданию цифровых продуктов. Язык может дать людям возможность создавать цельные продукты, даже если несколько участников работают над разными частями. Естественно, что некоторые люди будут погружены в это более глубоко, чем другие, но идея заключается в том, что все - дизайнеры, разработчики, исследователи, менеджеры по продуктам, производители контента - должны иметь некоторую степень беглости, и что беглость улучшается со временем, так как Команда продолжает изучать, использовать и развивать язык.
Но то, что Александр не упоминает в своей книге, - это именно то, сколько работы требует шаблонный подход. Средневековые соборы строились десятилетиями, и каменщики проходили годы ученичества, чтобы выучить язык узоров. Точно так же может потребоваться много усилий, чтобы создать общий язык в команде разработчиков и заставить его работать.
Но это можно сделать даже в больших командах. Мы можем начать с рассмотрения языковых решений, которые мы принимаем.
Джеймс Бриттон, влиятельный британский педагог, объясняет в « Language and Learning 1», что, присваивая имена объектам, мы начинаем «приводить их в чувство», точно так же, как дети используют язык, «чтобы извлечь из небытия» окружающий их мир. Точно так же, если объект интерфейса не имеет правильного имени - имени, которое известно и имеет смысл для людей в вашей команде, - тогда он на самом деле не существует в вашей системе как действенная единица для работы. Как только вы называете объект, вы формируете его будущее; если вы дадите ему презентационное имя, его будущее будет ограничено, потому что оно будет ограничено его стилем: «розовая» кнопка может быть только розовой.
Правильно выбранное имя может стать мощным инструментом для формирования вашей системы проектирования, поскольку имена влияют на то, как будут использоваться шаблоны. И, конечно же, речь идет не только о самих именах, но и о совместном подходе к именованию в вашей команде.
«Доброе имя» означает разные вещи для разных команд. Иногда требуется эксперимент, чтобы найти подход, который работает. Команда немецкой телекоммуникационной компании Sipgate 2 изначально использовала презентационные названия. Но они обнаружили, что такие имена, как «выдающаяся плитка» или «круг с точкой», не были эффективными и в конечном итоге способствовали фрагментации их системы.
«Основная проблема именования на основе презентаций заключается в том, что вы не можете найти то, что ищете, когда количество шаблонов в вашей библиотеке увеличивается. Это также не дает вам никакого руководства или вдохновения для того, где использовать определенный образец. Люди начинают создавать все новые и новые шаблоны вместо того, чтобы повторно использовать и улучшать существующие, что со временем делает проблему все хуже и хуже ».
- Тобиас Риттербах, владелец опыта, Sipgate
На Atlassian 3 компоненты названы с точки зрения пользователя. Например, «Lozenges» и «Inline Edit» получили свои названия, потому что именно так их называли пользователи. Сначала это было расценено как спорное и накладные расходы для разработчиков. Но команда чувствовала, что именование модулей таким образом позволяет инженерам думать с точки зрения пользователя и всегда иметь в виду пользователей.
«Это немного накладные расходы для инженеров, но в определенной степени мы стимулируем эмпатию пользователей»,
- Юрген Шпангл, руководитель отдела дизайна Atlassian
На FutureLearn 4 мы согласились, что доброе имя означает, что оно сфокусировано, запоминается и воплощает цель модуля, который оно представляет . Это имя, к которому люди относятся и хотят использовать . Как и другие команды, мы пробовали разные способы называть вещи - от более точных и описательных, таких как «Кнопка переключения прогресса», до забавных, таких как «Whisperbox». Посмотрев, как команда использовала модули, мы заметили, что наиболее эффективные имена в нашей системе обладали одним или несколькими из этих качеств: они были метафоричны, у них была личность, и они сообщали цель паттерна.
Метафора из других отраслей, таких как архитектура или издательство, может вдохновить доброе имя. Это также может сделать название более запоминающимся для команды, поскольку у них будет ассоциация - что-то, что можно себе представить - когда они подумают об этом модуле.
Скобки в архитектуре - это элементы, которые поддерживают и укрепляют структуру; например, помогая поддерживать крышу. Аналогичным образом, в интерфейсе FutureLearn «Скобки» также поддерживают основной контент, представляя небольшие порции дополнительной информации.
«Скобки» поддерживают основное содержание страницы, предоставляя дополнительную информацию.
Другим примером является «Spotlight»: рекламный элемент, предназначенный для привлечения внимания к определенной части контента.
«Spotlight» - это рекламный элемент, предназначенный для привлечения внимания к конкретному фрагменту контента.
«Скобка» и «Центр внимания» являются примерами эффективных имен - люди в команде знают и используют их. И наоборот, имена, с которыми не связана визуальная метафора, оказались менее эффективными.
Например, вряд ли кто-то может вспомнить, что такое «кнопка переключения прогресса» или как выглядит «двоичная радиокнопка».
Кнопка переключения прогресса.
Двоичная кнопка радио.
Проблема в том, что ни «Кнопка переключения прогресса», ни «Двоичная радиокнопка» не создают в вашем уме образ, который облегчает запоминание этих шаблонов. Даже если некоторые люди предпочитают более точное и описательное имя, такое как «Двоичная радиокнопка», этот факт никто не помнит. И если никто не помнит этого, есть большая вероятность, что люди воссоздают шаблон, а не используют его повторно.
Некоторые названия кнопок работали намного лучше. Есть небольшие вспомогательные функциональные кнопки, которые используются во всем интерфейсе FutureLearn. Их называют «Миньоны».
Кнопки миньонов.
И, конечно же, там, где есть миньоны, должен быть и босс. «Босс» FutureLearn - это большая кнопка, обычно основной призыв к действию на странице.
Кнопка босса.
Также интересно видеть .minionи .bossимена классов, используемые в CSS. 5
.minionи .bossимена классов в CSS.
Имена с личностью легче запомнить. Они не только держатся, но и вдохновляют другие имена и даже могут создать семейство имен. Модуль «Whisperbox» на FutureLearn был разработан для рекламы, не отвлекаясь. Когда другой команде понадобилось что-то более заметное, они создали «Boombox». «Whisperbox» и «Boombox» - это пара, которая помогает сделать словарь более связанным и запоминающимся.
Лучшие имена предлагают руководство или вдохновение для того, где использовать определенный образец. Легко запомнить, что может быть много миньонов (на странице), но только один босс. Людям нравится их использовать, и нам не нужно применять правила, потому что они идут вместе с названием. Даже несколько таких имен могут помочь сделать ваш словарный запас более убедительным, и команда с большей вероятностью воспользуется им и внесет свой вклад.
Имена позволяют нам не только определять и различать шаблоны, но и описывать, для чего они нужны. Называть шаблоны особенно сложно, когда мы не до конца поняли их назначение. Если вам не удается придумать имя, скорее всего, что-то не так. Возможно, цель модуля неясна, или она совпадает с целью другого; в любом случае, это красный флаг, который вы должны заметить.
Один из модулей в новом интерфейсе Eurostar был представлен специально для улучшения SEO. Во время семинара по библиотеке шаблонов команда изо всех сил пыталась придумать название: «Это модуль SEO! У него нет функции. Нет смысла в его существовании! »
Модуль, введенный в интерфейс Eurostar специально для улучшения SEO.
Название, которое они дали в конце, было «le blurb». И целью le blurb было что-то вроде: предоставить потенциально интересную информацию с потенциалом для SEO.
Приближение к сложным именным решениям с юмором может помочь. И все же это почти никогда не трудно без причины. В какой-то момент мы должны спросить себя: что здесь не так? Почему мы не можем придумать имя?
Мы можем лучше понять назначение шаблона, если процесс именования в нашей команде будет совместным. Это не означает участие всей компании: речь идет не о количестве людей, а о разнообразии точек зрения. Слишком часто ответственность за именование модулей ложится на разработчиков, когда они пишут CSS, но это можно сделать проще (и веселее), если расширить процесс именования, чтобы включить в него больше людей из команды.
Люди из разных дисциплин будут смотреть на модуль немного по-своему. Кто-то из фонового контента может увидеть его в общем виде, потому что он должен быть гибким. Разработчики могут увидеть технические особенности, потому что они знают о том, как построен модуль - они будут знать, что что-то является переключателем, даже если это не похоже на переключатель. Дизайнеры и пользователи могут быть более знакомы с исходным поведением, которое должен поддерживать шаблон. Привлечение людей с различными точками зрения может помочь принять более обоснованное и объективное решение о назначении модуля. И как только вы знаете цель, придумать имя легче.
Совместное именование также поможет членам команды, которые не проектировали и не создавали шаблоны, понять их использование. Например, привлечение контент-команды может помочь привлечь их в качестве участников этого процесса, а не просто передать стопку ящиков для заполнения.
Один из самых простых способов совместной работы над именами - это создать выделенное пространство в вашем любимом приложении для повседневного общения (например, канал Slack «Система проектирования»). Поделитесь с командой макетом дизайна или существующим модулем и кратко опишите, для чего он нужен и чем он отличается. Вы можете сказать: «Обычно это дополнительная или вспомогательная информация, разделенная на более мелкие фрагменты». Это может помочь поделиться именами, которые вы придумали до сих пор.
«Самородки радости» могут быть отличным названием для модуля, но мы решили остановиться на «Скобках» в этом случае.
Несколько человек присоединятся к обсуждению, зададут вопросы и предложат свои идеи. Некоторые предложения не будут совершенно правильными, другие будут смешными или неожиданными. Это нормально - дело в том, чтобы вызвать дискуссию. Обсуждение проектных решений и назначения шаблонов помогает укреплять и развивать общий язык. 6 Если вы придумали доброе имя, не забывайте отдавать людям должное и праздновать его. Это те моменты, которые помогают объединить команду и сделать совместное именование частью вашей культуры.
Возможно, вы захотите пойти еще дальше и вовлечь своих пользователей в языковые решения. Попробуйте протестировать модули на бумажных карточках. Тестирование на картах отличается от других методов исследования пользователей, которые используют линейные задачи и сценарии, через которые пользователи могут работать. Здесь участники могут собирать карточки, перемещать их, обсуждать и писать на них, активно участвуя в процессе проектирования. Это может дать вам возможность проверить свой выбор языка и убедиться, что определенные вами модули соответствуют потенциальному поведению ваших пользователей и ментальным моделям. В некоторых случаях вы можете обнаружить, что ваши «видные вкладки» полностью игнорируются или что ваш «элемент управления Wizard» интерпретируется как набор дополнительных вкладок.
Пользовательское исследование с вырезанными модулями.
Как бы ни было полезно вовлекать членов команды и пользователей в процесс именования, важно оставаться сосредоточенным и не зацикливаться на бесконечной дискуссии. Иногда слишком много входных данных может привести к разбавленным или запутанным именам. Чтобы избежать этого, в FutureLearn мы бы приняли предложения, но всегда оставляли окончательное решение за парой дизайнер-разработчик, которая работала над модулем.
Однако одного названия вещей недостаточно для установления общего языка. Вся команда должна быть погружена в это. Сделайте это вездесущим. Если вы создадите правильные условия, даже люди, которые изначально не заинтересованы, будут учиться пассивно, через воздействие. Вот несколько советов по созданию таких условий.
Установите выделенное пространство на стене, чтобы визуально представить вашу систему дизайна: модель стены.
Настенная модель в офисе FutureLearn.
Узорная стена дает вам представление о вашей системе с высоты птичьего полета. Это делает его отличным местом для именования разговоров, так как вы можете ссылаться на вещи прямо перед вами - не нужно искать по всему сайту или помнить, как они выглядят. Наличие выделенного пространства также делает вашу систему более открытой: люди чувствуют, что они могут присоединиться, задать вопросы и внести свой вклад.
Вам не нужно много места, чтобы создать узорную стену, и не все экраны вашего продукта должны быть там. Начните с тех, которые являются наиболее важными или используются наиболее часто. Распечатайте их на листах формата А3, повесьте на стену и обозначьте наиболее заметные узоры. Это может быть полезно расположить распечатки в порядке, который следует за вашими наиболее распространенными поездками пользователей; например: экраны обнаружения, вход в систему, сравнение продуктов, совершение покупки.
Вы можете проявить творческий подход, делая свои шаблоны дизайна видимыми. Команда MOO, компании, занимающейся цифровой печатью и дизайном, напечатала некоторые страницы из своего руководства по стилю на открытках MOO в виде удобных листов, которые сотрудники могут взять для справки.
Некоторые из руководств по стилю MOO.
Автоматические напоминания также могут быть полезны. Это займет всего несколько минут, чтобы настроить бот Slack, который будет иногда напоминать вашей команде, как называются различные элементы. 7
Slack-бот, напоминающий команде, как выглядит «Signpost».
Как и с любым языком, вы должны использовать его, чтобы поддерживать его. Это должно быть частью повседневных разговоров. Вот почему важно прилагать сознательные усилия, чтобы продолжать ссылаться на шаблоны по именам, с которыми вы согласились - независимо от того, насколько странным это может звучать.
«Whisperbox» - это рекламный модуль на FutureLearn. Как следует из названия, оно должно быть тонким и не привлекать к себе слишком много внимания.
«Whisperbox»: тонкий рекламный модуль на FutureLearn.
Пока мы не дали ему правильное имя, мы продолжали называть его «тем, что с линиями и значком посередине». Это было легко назвать так. Потребовалось больше усилий, чтобы начать называть его «Whisperbox». Но до тех пор, пока вы не начнете называть шаблон его фактическим именем, он не существует в вашей системе как надежный блок для работы. И каждый раз, когда вы используете имя, вы усиливаете элемент, к которому обращаетесь, и развиваете свой язык дизайна.
Это требует определенной самодисциплины в команде. Это может быть сложно, особенно если вы к этому не привыкли (представьте, что вы присоединились к команде, где все говорят о миньонах, боссах и шепотах!). Но очень скоро эти имена становятся частью нормального разговора, и люди к нему привыкают. Цель состоит в том, чтобы добраться до точки, где все точно знают, о чем вы говорите, просто назвав имя. Все знают цель навигации по последовательностям и называют ее «навигацией по последовательностям», а не «причудливыми пузырьками» или «волшебным контролем». Естественно, это также означает, что имена в файле проекта и коде совпадают .
Проще ввести новых сотрудников в вашу систему проектирования, если это часть вашего вводного процесса. Новые члены команды Atlassian рассказывают о том, как были созданы руководящие принципы, чтобы они могли понять, почему и как были приняты решения. В FutureLearn мы создали внутренний вводный онлайн-курс, который включает в себя отдельную главу о библиотеке шаблонов, с викторинами и уроками размера укуса.
Глава о библиотеке шаблонов в вводном онлайн-курсе FutureLearn.
Все ненавидят встречи. Но догадки системы проектирования имеют смысл, если вы хотите, чтобы все развивались на одной странице при разработке вашей системы. Это время, когда все дизайнеры и разработчики могут полностью сосредоточиться на системе вместе.
Догоны могут работать с группой из 16–20 человек, а для больших групп люди могут по очереди посещать занятия. Они не должны занимать много времени - обычно достаточно получаса, если у вас хорошо структурированная повестка дня. Первоначально вы можете запускать их еженедельно, а затем каждые две недели, когда команда находит свой ритм. Команды могут использовать это время для согласования общих шаблонов, таких как значки или типографика для всего продукта. Это также хорошая возможность поделиться новыми модулями и обсудить их назначение, использование и любые проблемы и вопросы, которые могут возникнуть у людей.
Постарайтесь объединить усилия при проектировании и построении шаблонов. Все упражнения, описанные в предыдущих двух главах, могут помочь сотрудничеству и установить общий язык между дисциплинами:
• Создание карты шаблона
• Проведение инвентаризации интерфейса, ориентированной на определенный шаблон.
• Рисование структуры рисунка
• Согласование цели шаблона и придумывание имени
• Изложение моделей, которые заставляют ваш продукт чувствовать себя определенным образом
• Проведение небольших экспериментов с новыми моделями
В любой команде будут люди, которые более свободно владеют языком шаблонов и более увлечены работой в системе, и они, естественно, могут стремиться работать друг с другом. Но попытайтесь побудить их работать со всеми, чтобы у них была возможность поделиться своими знаниями и энтузиазмом с людьми, которые менее погружены в систему. Распространяя знания по всей организации, система проектирования становится более устойчивой.
Одним из наиболее эффективных методов обмена и развития языка дизайна является сохранение глоссария используемых вами терминов. Создание и хранение глоссария позволяет вам осознанно понимать слова, которые вы используете, так как вы должны четко формулировать и записывать их. Например, в Intercom, платформе для обмена сообщениями с клиентами, команда ведет глоссарий терминов, чтобы убедиться, что они используют «один и тот же язык от кода к клиенту».
И, конечно же, современная, легкодоступная библиотека шаблонов также может быть надежным глоссарием шаблонов проектирования и ориентиром для всей команды (а также фактическим набором шаблонов для проектирования и создания интерфейса). , 9
Ценность глоссария заключается не только в том инструменте, который он предоставляет, но и в языковых практиках, которые он развивает. Создавая и сохраняя глоссарий, вы приобретаете привычку проверять, обсуждать и формулировать свои языковые решения в команде - вы признаете, что слова важны.
Не все команды одинаково сотрудничают и открыты для обсуждения принципов и шаблонов дизайна каждый день. Создание общего языка требует определенного вида командной культуры. Но это также может работать и наоборот - интеграция процессов, ориентированных на язык, может привести к улучшению сотрудничества. Три года назад в FutureLearn у нас не было рабочего языка общего дизайна, и мы работали не так много, как сегодня. Дизайнеры документировали шаблоны в фирменном документе в формате PDF, а разработчики создавали свое руководство по стилю. Хотя оба документа были полезны для каждой из дисциплин, они не обеспечивали общую языковую основу для работы. Но, внедрив методы и процессы, мы постепенно изменили то, как мы работаем.
Установление общего языка всегда постепенный, частичный процесс. Иногда это будет грязно и медленно, но если вы просто продолжите, ваш язык будет развиваться и укрепляться. В конце концов, эффекты будут распространяться внутри вашей команды, с другими командами и заинтересованными сторонами, когда они начнут понимать, чего вы пытаетесь достичь, и присоединитесь к вам в этом процессе.
-
1. http://smashed.by/languagelearning
4. https://www.futurelearn.com/
5. В интерфейсе FutureLearn есть больше стилей кнопок, примеры, показанные здесь, являются одними из самых эффективных.
6. Более того, когда вы делитесь новым дизайном, кто-то может заметить, что подобный модуль уже существует, и вы можете предотвратить дублирование.
7. Некоторые инструменты, такие как Brand.ai и Frontify, также имеют интеграцию со Slack для проверки связи с каналами при обновлении библиотеки шаблонов. Подробнее об инструментах в главе 10.
9. Мы подробно обсудим библиотеки шаблонов в главе 10.
В этой первой части книги мы говорили о создании основ системы проектирования. Вот краткое изложение ключевых моментов.
Цель системы проектирования - помочь в достижении цели продукта: «Приготовить здоровую еду за десять минут»; «Распространите переговоры как можно дальше и шире»; «Правильная музыка для каждого момента». Все в системе - от того, как работает команда, до самого маленького паттерна - должно быть оптимизировано для этой цели.
Команды выбирают, как достичь цели продукта через дизайн. Их подход к дизайну и приоритеты могут быть отражены в ряде принципов: «Дизайн для первых впечатлений»; «Соответствует более последовательным»; «Вечный, а не передовой». Чем более сплоченная команда придерживается своих принципов, тем более сплоченные модели они создают.
Через интерфейс мы стремимся помочь людям достичь определенных целей и почувствовать определенный путь: выучить новый рецепт; сосредоточиться на письме; чувствовать себя продуктивным; чувствовать себя вдохновленным Наше дизайнерское намерение передается через шаблоны проектирования. Функциональные шаблоны поддерживают поведение и действия пользователей: «выберите ингредиенты», «выберите рецепт», «следуйте инструкциям рецепта», «оцените рецепт». Шаблоны восприятия фокусируются на том, как продукт должен чувствовать себя интуитивно: «утилитарный», «газетный» , »« Откровенно восторженный ». Команда должна тщательно понимать цель шаблонов. Только тогда мы сможем удостовериться в том, что он интерпретируется так, как задумано нашими пользователями.
Шаблоны должны быть связаны через общий язык - глубоко укоренившиеся знания в команде о том, как создавать и использовать шаблоны проектирования для конкретного продукта для создания эффективного и согласованного пользовательского опыта. Эти знания распространяются через общий подход к проектированию, интерфейсную архитектуру, видение бренда и повседневные практики, такие как совместное именование, междисциплинарное спаривание, отображение шаблонов, регулярные инвентаризации интерфейса и поддержка библиотеки шаблонов. Язык должен развиваться, укрепляться, повторяться и постоянно тестироваться.
Система проектирования строится не быстро, а постепенно, в соответствии с нашей повседневной практикой. Если вы работаете над цифровым продуктом, основы вашей системы, вероятно, уже существуют. Так или иначе, интерфейсы спроектированы и построены и оказываются перед пользователями. Если этот процесс не является полностью случайным, у вас есть система. Вопрос в том, что это за система? Это гибкий и адаптируемый или он предназначен для одной конкретной цели? Это связное или фрагментированное? Легко ли работать или это отнимает много времени? Ваша система процветает на свободе и автономии, или это строго иерархически?
Чтобы сделать систему проектирования более эффективной, нам нужно знать, как она работает, из чего она состоит, что делает ее функционирующей хорошо, а что нет. Если у нас нет этих знаний, одни и те же проблемы продолжают происходить (систематически!). Мы убираем все кнопки, и через шесть месяцев снова получаем слишком много кнопок. Мы можем решить проблему, но если механизм, который ее создал, останется, та же проблема продолжит возвращаться.
Различные системы проектирования работают по-разному. Ваша организация, командная культура, подход к проектированию, проект и даже физическое пространство, в котором вы находитесь, будут формировать вашу систему. В следующей части книги мы начнем с рассмотрения базовых структур, которые влияют на системы проектирования. Затем мы сосредоточимся на методах создания и поддержки системы проектирования, включая: планирование; проведение инвентаризации функционального интерфейса; настройка библиотеки шаблонов; и создание, документирование, развитие и поддержание шаблонов проектирования.
В этой главе рассказывается о некоторых качествах, которые может иметь система проектирования, и о способах управления рисками и недостатками.
Команда немецкой телекоммуникационной компании Sipgate столкнулась с проблемой. Дубликаты и несоответствия на сайтах их продуктов разбавляли бренд и создавали ненужную дополнительную работу для всей команды. Они решили решить эту проблему путем создания библиотеки шаблонов. После нескольких недель семинаров и инвентаризации интерфейсов модели на всех сайтах были стандартизированы. Через несколько месяцев команда выпустила новую библиотеку шаблонов.
В некоторых компаниях вам может быть сложно заинтересовать людей своей библиотекой шаблонов. Они не увидят его ценность, они не будут способствовать. Это было не так в Sipgate. Все команды разработчиков тщательно и эффективно документировали свои шаблоны. Не было недостатка в энтузиазме. Но через год было так много модулей, что стало чрезвычайно трудно найти тот, который они искали, и понять, какой из них использовать. Стало проще просто добавить новый. После года поддержки библиотеки шаблонов их веб-сайты по-прежнему были заполнены дублированными шаблонами, хотя и тщательно документированными.
Система проектирования не начинается и не заканчивается созданием библиотеки шаблонов. Есть много факторов, которые формируют систему: структура вашей организации, культура вашей команды, тип продукта, над которым вы работаете, и ваш подход к дизайну, среди прочего.
Чтобы увидеть, как эти факторы работают, я считаю полезным охарактеризовать системы проектирования, используя три атрибута: строгость правил, модульность частей и распределение организации.
Эти параметры не являются двоичными, и все компании лежат где-то на каждом континууме. При более внимательном рассмотрении их мы будем опираться на примеры разных компаний, чтобы увидеть преимущества и недостатки каждого направления.
Некоторые системы являются строгими, другие выигрывают от более свободной настройки. В качестве примера возьмем две команды: Airbnb и TED.
Airbnb насчитывает более 2000 сотрудников по всему миру и около 60 дизайнеров продуктов, работающих в нескольких рабочих потоках. Система полностью управляется их командой Design Language System (DLS), которая состоит из шести дизайнеров и их партнеров по разработке веб-платформ, мобильных устройств и платформ React Native.
Система проектирования в Airbnb строгая: существуют четкие правила и процессы, которые строго соблюдаются.
Чтобы минимизировать отклонения, модули в DLS Airbnb указаны точно. Например, типография лечения строго определены; для интервалов используется сетка из восьми пикселей; взаимодействия документированы; Соглашения об именах согласуются. Вот как модуль «Marquee» указывается в главном файле Sketch. Обратите внимание, что есть два примера каждого из них, чтобы показать некоторые варианты, доступные для дизайнеров.
Модуль «Marquee» в главном файле Sketch Airbnb.
В системе Airbnb дизайн и проектирование полностью синхронизированы. В частности, это означает три вещи:
• Модули проектирования в главном файле Sketch имеют точный эквивалент в коде и синхронизированы.
• Имена в файле эскиза и код совпадают.
• Все модули являются кроссплатформенными: каждый компонент, нарисованный в файле Sketch, имеет соответствующий компонент, который максимально похож в iOS, Android, React Native и адаптивных веб-библиотеках.
Синхронизация рассматривается как приоритет. Для этого команда создает собственные инструменты, такие как подключаемые модули Sketch.
Шлюз для всех ресурсов DLS.
Команда DLS стремится предоставить все шаблоны, требуемые дизайнерами по всей компании. Их цель - повторно использовать около 90% существующих модулей, поэтому создание новых шаблонов встречается относительно редко. Существует строгий процесс введения новых компонентов:
1. Дизайнер подает предложение с использованием шаблона Sketch с инструкциями о соответствующем поведении и правилах. Они предлагают подходящее имя и предоставляют пример того, как предлагаемый компонент может использоваться в контексте.
2. Затем предложение отправляется в службу поддержки продукта через JIRA вместе с файлом Sketch. Во многих случаях группа поддержки обнаруживает, что подобный модуль уже существует или что существующий модуль должен быть обновлен.
3. Если необходимость в новом модуле оправдана, предложение передается команде DLS, которая рассматривает требование и решает, будет ли предложенный проект работать. Иногда они используют предложенное решение, иногда они адаптируют или переделывают его, чтобы убедиться, что оно соответствует системе.
Язык разработки задокументирован на внутреннем веб-сайте DLS Guidelines, сгенерированном из основного файла Sketch. Команда разработчиков Airbnb создала автоматизированный процесс, который генерирует скриншоты и метаданные о компонентах и публикует их на сайте рекомендаций. Излишне говорить, что документация полностью синхронизирована с файлом Sketch и кодом.
Внутренний веб-сайт DLS Guidelines.
Вот некоторые из методов, которые делают DLS функционирующим как строгая система. На противоположном конце шкалы строгости у нас есть компании с более слабыми структурами. Такие системы оптимизированы больше для экспериментов и чувствительности к контексту. Они тоже могут быть эффективными.
Команда в TED небольшая, всего пять или шесть ключевых людей, ответственных за решения системы проектирования: два специалиста по UX и четыре разработчика переднего плана. Система TED слабо настроена. Чувство бренда и полезность страницы имеют приоритет над идеальной визуальной последовательностью. Например, введение дополнительного цвета или отклонение от стандартного макета в качестве исключения не является серьезной проблемой, если оно помогает достичь правильного эффекта:
«Проектируйте то, что правильно, а не то, что наиболее последовательно. Лучшая утилита страницы является приоритетом. Мы изменим страницу, чтобы она работала. Догматическая последовательность и устоявшиеся шаблоны - это не то, что должно
влиять на проектные решения ». - Майкл МакВаттерс, UX-архитектор, TED
Существует много возможностей для творческих экспериментов с такой системой. Поскольку каждая страница может быть точно настроена, она может адаптироваться к конкретным условиям и случаям использования. Проекты, которые генерирует такая система, могут быть последовательными, но они не обязательно идеально согласованы. В отличие от Airbnb, процессы TED также более спокойные и неформальные.
Вместо подробных спецификаций команда TED часто может использовать скетч с белой доски или бумаги с элементарной запиской. Затем он передается лично или публикуется в Dropbox или InVision, где команда обменивается комментариями и отзывами. Затем дизайнеры и разработчики работают совместно, чтобы повысить их достоверность.
В TED часто используется простой набросок с примечаниями, а не подробный дизайн.
Документация также проста. У команды нет обширной библиотеки шаблонов. Вместо этого есть простая коллекция того, что они называют образцами, на веб-странице и в файле Sketch, который содержит некоторые из их основных шаблонов проектирования - но далеко не все.
Некоторые образцы TED, сохраненные в файле Sketch.
Возможно, вы думаете, что это потому, что TED маленький, и у него просто нет времени и ресурсов для создания всеобъемлющей библиотеки шаблонов. Но это не совсем так. До сих пор не было необходимости документировать все подробно. Если команда начинает расти, это может измениться, но они подчеркивают, что даже при наличии библиотеки шаблонов шаблоны не будут влиять на дизайн. «Проницательность дизайна и чувствительность к контексту всегда будут на первом месте, даже если это означает, что в некоторых случаях шаблоны будут игнорироваться или изменяться», - говорит Майкл МакВаттерс.
Несмотря на то, что дизайн интерфейсов TED адаптируется к уникальным контекстам, иногда выходящим за рамки установленных контекстов, команда по-прежнему считает, что их система эффективна в создании проектов, которые работают для их пользователей. Существует много преемственности и согласованности в их бренде и пользовательском опыте.
То, что заставляет работать такую систему, это не строгие правила и процессы - это общие знания о дизайне, глубоко укоренившиеся в культуре. Команда полностью согласовывает свое видение продукта («Распространите идеи как можно шире и шире») и подход к их дизайну. Проектирование шаблонов руководствуется общими принципами (такими как «Вечный, не ультрасовременный»), и существует глубокое взаимное понимание назначения шаблонов и их использования. Эти общие знания являются основой, которая делает эту систему эффективной, даже если она слабо настроена.
Это были два противоположных примера, но, конечно, эти параметры не являются двоичными: все команды находятся где-то в этом масштабе. Может показаться, что строгость связана с размером компании - младшие меньшие системы имеют тенденцию (и могут сойти с рук) быть более свободными, чтобы дать больше свободы и экспериментов. По мере роста системы она становится все строже. Но, возможно, все не так просто. Однажды я работал в небольшой команде с блестящим, но авторитарным креативным директором, который внимательно следил за всем выходом дизайна. Это была маленькая, но очень строгая система. С другой стороны, вы можете представить себе более крупную компанию со слабо настроенной системой, которая будет стимулировать каждую команду экспериментировать и принимать собственные решения. Возможно, дело не в размерах, а в подходе команды и ее приоритетах.
В целом, более строгие системы обеспечивают точные и предсказуемые результаты и визуальную согласованность. Но в то же время строгая система может стать жесткой до такой степени, что вы начнете идти на компромиссы UX ради согласованности.
Чтобы этого не происходило, должны быть возможности за пределами системы, такие как творческие эксперименты и сторонние проекты. Люди должны понимать правила и уметь их оспаривать. Если нет понимания, правила будут игнорироваться или переопределяться. Вот почему четкая, всеобъемлющая и убедительная документация является фундаментальной для этого типа системы.
Слабо настроенные системы хорошо подходят для продуктов, которые отдают приоритет чувствительности к контексту и экспериментам. Но свободная система, которая так хорошо работает для TED, может быстро стать слишком грязной и фрагментированной в других компаниях.
Чтобы иметь простую, гибкую систему, такую как TED, каждый в команде должен быть полностью согласован с целью продукта и подходом к дизайну, которые оба должны быть глубоко внедрены в их культуру. Даже слабо настроенная система нуждается в прочном фундаменте.
Все системы сделаны из частей. Но в контексте систем проектирования модульность означает не только то, что система состоит из частей, но и то, что части являются взаимозаменяемыми и могут быть собраны вместе различными способами для удовлетворения различных или меняющихся целей пользователя.
Модульная конструкция, такая как культовый конструктор Bauhaus Bauspiel, может адаптироваться к различным требованиям.
Модульный подход имеет много известных преимуществ:
• Это гибко, потому что несколько команд могут проектировать и создавать модули параллельно.
• Это экономически выгодно, поскольку эти модули можно использовать повторно.
• Его относительно легко обслуживать, поскольку вы можете исправить проблему в одном модуле, не затрагивая другие.
• Это адаптируется, потому что модули могут быть собраны таким образом, чтобы удовлетворить различные потребности пользователей.
• Он может иметь генеративное качество, что означает, что вы можете создавать совершенно новые результаты, вводя новые шаблоны или комбинируя их по-новому.
Противоположностью модульной структуры является комплексный подход к проектированию. Интегрированная конструкция также может быть изготовлена из частей, но эти части не являются взаимозаменяемыми, поскольку соединения между ними не рассчитаны на различные варианты.
Интегрированный дизайн оптимизирован для достижения конкретной цели.
Интегрированные конструкции также имеют ряд преимуществ:
• Они могут быть специфическими для конкретного контента, контекста, истории или художественного направления.
• Они имеют тенденцию быть более связными и связанными (в отличие от модульных структур, которые могут чувствовать себя не связанными).
• Они могут быть построены быстрее как одноразовые, потому что нет необходимости тратить время на повторное использование деталей.
• Их легче координировать, так как все в команде работают ради одной цели.
Наши разговоры о системах проектирования в Интернете были в пользу модульности и стандартизации компонентов. Мы говорим о том, как шаблоны должны быть модульными и многоразовыми, как все должно быть как у Lego. Но степень модульности должна зависеть от вашей команды и вашего продукта.
Помимо эффективности и экономии средств, подумайте о том, как модульный подход может принести пользу вашим пользователям и повысить удобство использования вашего продукта. В архитектуре есть примеры, когда модульность не только добавляет опыта, но и становится его основной характеристикой.
Puma City - это розничный магазин, состоящий из 24 грузовых контейнеров, которые можно разобрать и собрать. Что позволяет этому зданию путешествовать по всему миру, так это его модульность. Это также является ключом к его дизайну: контейнеры собраны таким образом, что формирует индивидуальность здания. Сдвиг контейнеров по-разному может создать открытые пространства и террасы, а также интерьер. Даже то, как логотип фрагментируется в результате перемещения контейнеров, является частью композиции, частью уникального ощущения этого здания.
Пума Сити, ЛОТ-ЭК.
Теперь давайте рассмотрим пример интегрированной архитектуры. Жилой комплекс Greendo в Такамацу, Япония, построен на склоне горы и имеет пять уровней; крыша каждого блока служит чужим садом. Мало того, что здание встроено в ландшафт, оно также живет и дышит землей, используя естественную изоляцию и тепло от земли для поддержания стабильной температуры внутри.
Гриндо, Кейта Нагата.
Иногда модульность имеет смысл на уровне реализации, но не в дизайне, или наоборот. Это жилье для студентов в Париже выглядит модульным, как будто оно построено из сдвигающихся корзин, повернутых под разными углами.
Корзина квартир, OFIS архитекторов.
Но на самом деле именно расположение балконов и то, как они выступают из здания, придает ему такое ощущение. В этом случае не имело смысла делать здание полностью модульным, но модульная эстетика по- прежнему подходила именно этому зданию. Может быть и обратное.
Короче, модульность не всегда лучше. Степень модульности должна зависеть от того, чего вы пытаетесь достичь.
В целом, модульный подход подходит для продуктов, которые:
• необходимо масштабировать и развиваться
• необходимо адаптироваться к различным потребностям пользователей
• иметь большое количество повторяющихся частей
• иметь несколько команд, работающих над ними одновременно и независимо
Примерами могут служить крупномасштабные сайты для электронной коммерции, новостей, электронного обучения, финансов, государственного управления - все, что нужно для масштабирования, развития и удовлетворения потребностей различных пользователей.
Я нахожу это особенно интересным, когда модульность становится частью бренда и опыта продукта. Например, во Flipboard модульные макеты лежат в основе дизайна и бренда. Это то, что помогло сделать бренд особенным: «Каждый макет страницы журнала выглядит вручную и красиво - как будто редакторы и дизайнеры создали его только для вас». 1
Модульные макеты Flipboard лежат в основе пользовательского опыта.
С другой стороны, интегрированные системы подходят для продуктов, которые:
• предназначены для одной конкретной цели
• не нужно масштабировать или изменять
• требовать художественного руководства за пределами системы
• иметь несколько общих повторяющихся частей
• являются однократными, которые вряд ли будут повторно использованы
Примерами интегрированного подхода могут быть креативные веб-сайты конференций, разовые маркетинговые кампании, креативные портфолио и демонстрации.
![Circles Conference - это конференция для дизайнеров и других креативщиков. Его сайт отличается смелым дизайном и множеством уникальных модулей, которые делают полную модульность не стоящей. [KIKK.be], 2016](./Системы Проектирования_files/000079.png)
Circles Conference - это конференция для дизайнеров и других креативщиков. Его сайт отличается смелым дизайном и множеством уникальных модулей, которые делают полную модульность не стоящей. ( KIKK.be , 2016)
Кампании Spotify имеют совершенно разные дизайны при продвижении определенных музыкальных событий.
Примеры рекламных кампаний Spotify.
Хотя вы можете заметить некоторое повторное использование нескольких стилей бренда (таких как формы, цвет и типографика), в этих кампаниях реже можно увидеть более крупные строительные блоки из основных потребительских товаров. Чтобы обеспечить большую гибкость и творческое самовыражение, имело больше смысла создавать эти конструкции вне их модульной системы для потребительских товаров. 2
Модульный подход является адаптируемым, масштабируемым и экономически эффективным в долгосрочной перспективе. Но модульность имеет некоторые недостатки.
Во-первых, создание многократно используемых модулей обычно занимает больше времени, чем создание одноразового решения, предназначенного для достижения конкретной цели. Вы должны продумать различные варианты использования и спланировать, как они будут работать в системе. Чтобы стать экономически эффективным, необходимо повторно использовать модули, что может занять некоторое время. Некоторые команды некоторое время борются, чтобы увидеть возврат инвестиций в модульную систему, что в первую очередь затрудняет оправдание инвестиций.
Во-вторых, модули, как правило, должны быть достаточно общими, чтобы соответствовать различным случаям. Результатом могут быть предсказуемые общие проекты, в которых сила композиции и сюжета теряется в пользу эффективности. Когда команды выбирают модульный подход, им необходимо найти другие способы для инноваций - особый контент или сервис, сильный голос или эффективное использование шаблонов восприятия.
В-третьих, чтобы иметь смысл модульности, команды иногда вынуждают повторно использовать модули. В FutureLearn мы иногда жертвовали потенциальным влиянием, которое страница может оказать для повторного использования. Чтобы этого не происходило, техническая эффективность всегда должна быть сбалансирована с преимуществами, которые модульность приносит пользователю.
Наконец, одна из основных проблем - это бесшовное соединение модулей. Модульная конструкция предполагает, что вы можете смешивать и сочетать детали, и они должны идеально сочетаться друг с другом. Но иногда люди комбинируют модули так, что они не работают в целом. И, как это ни парадоксально, даже при том, что между модулями существует большая согласованность, в общем опыте наблюдается небольшая согласованность. Чтобы предотвратить это, мы должны сосредоточиться не только на модулях, но и на связях между ними: правилах их отношения друг к другу, их относительной важности (такой как визуальная громкость), их роли в общем пути пользователя, их иерархия в общем составе.
Интегрированные проекты могут быть более конкретными, поскольку они оптимизированы для одной цели. Они также имеют тенденцию быть более связными и работать лучше в целом. Но они плохо масштабируются. Интегрированные проекты нельзя адаптировать или использовать повторно, что часто является именно тем, что нам нужно в Интернете.
Степень модульности может меняться со временем. Ваша система может начинаться с нескольких общих стилей и принципов. По мере роста вы можете заметить все больше и больше повторяющихся шаблонов, и увеличение модульности становится логическим развитием вашего продукта.
В равной степени он может развиваться в противоположном направлении. В FutureLearn у нас в основном модульная система. Но мы заметили, что необходимость работать с шаблонами многократного использования на высокоэффективных страницах продаж может показаться ограничивающей. С тех пор как FutureLearn начала проводить больше маркетинговых кампаний под брендом, мы работаем с большим количеством пользовательских разделов, чтобы сделать бренд более сильным.
Другим важным аспектом системы проектирования является то, как она организована.
В централизованной модели правила и шаблоны управляются в основном одной группой людей. Обычно это означает, что:
• они определяют шаблоны и правила
• они имеют право вето на систему
• они управляют библиотекой шаблонов или другими ресурсами, где хранятся шаблоны
Наиболее очевидным преимуществом этой структуры является собственность. Если кто-то несет ответственность за это, более вероятно, что система будет курироваться, обслуживаться и развиваться. Это также помогает творческому направлению быть сосредоточенным и мнительным, потому что оно исходит из одного источника. Вероятно, поэтому иногда мы находим эту модель в таких компаниях, как Apple или Airbnb.
Альтернативным подходом является распределенная модель, в которой каждый, кто использует систему, также несет ответственность за ее поддержку и развитие.
Этот тип структуры обеспечивает автономию для отдельных лиц и дает им возможность принимать решения. Это имеет тенденцию быть более проворным и гибким - если одна команда что-то упускает, другая может поднять это. Знания о дизайне и креативное направление распределены, а не сконцентрированы в умах нескольких людей. 3
Это подход, используемый в TED, а также структура, которую мы пытались установить в FutureLearn. Для небольшой компании, такой как FutureLearn, было непрактично иметь специальную команду разработчиков систем проектирования. Все дизайнеры и внешние разработчики, работающие над продуктом, также активно участвуют в создании системы. И поскольку каждый вносит свой небольшой вклад, запуск системы таким способом не займет много времени. Это единственный способ сохранить библиотеку шаблонов за последние три года.
Хотя распределенный подход работает для FutureLearn, он не для всех. Многие компании, с которыми я говорил, имели другой опыт, когда пытались. Сначала люди были полны энтузиазма, но без ответственного лица работа могла замедлиться или полностью остановиться.
Команда в Eurostar невелика: она состоит из четырех дизайнеров, четырех менеджеров по продуктам и десяти разработчиков. Распределенный подход изначально имел практический смысл для команды такого размера. Но через год они все еще изо всех сил старались сделать так, чтобы все делали взносы равномерно.
«Мы хотели, чтобы каждый внес небольшой вклад. Но вместо этого мы увидели, как несколько человек внесли большой вклад ».
- Дэн Джексон, архитектор решений, Eurostar
После перехода на централизованный подход команда достигла гораздо больших успехов.
Библиотека шаблонов Евростар 4 , 2017.
Полностью распределенный подход, похоже, требует определенного типа командной культуры для работы. Точно так же строгая система также терпит неудачу без культуры, чтобы поддержать это. На BBC централизованный подход не совсем сработал с GEL. Бен Скотт, технический руководитель BBC, поделился в интервью, что, несмотря на расследование централизации их системы, это не стоило того, потому что у каждой команды разработчиков всегда было свое собственное мнение о том, каким должен быть их дизайн. Таким образом, распределенный подход работал намного лучше. 5
Централизованный подход обеспечивает владение и надежность. В то же время, это может работать против команды. Поскольку ответственность ложится на одну группу людей, они могут стать узким местом, замедляя весь жизненный цикл продукта. 6 Для небольших команд, таких как FutureLearn или TED, также может быть нецелесообразно отнимать кого-либо от продукта, чтобы позволить ему посвятить большую часть своего времени сосредоточению на системе.
Распределенный подход способствует большей автономии и дает возможность всей команде создавать. Это более проворно, более гибко, потому что это не зависит от небольшой группы людей. Но сложно сделать так, чтобы это было устойчивым и не ослабляло креативность.
Как и относительная строгость правил системы и степень ее модульности, способы организации системы не зависят от размера команды. В небольшой компании креативное направление может исходить из единого источника, такого как генеральный директор или креативный директор. В более крупных компаниях также может работать распределенная система.
Например, Atlassian - это относительно крупная организация с более чем 2000 сотрудников. Есть специальная команда, которая разрабатывает шаблоны, но есть и модель с открытым исходным кодом для вклада. Каждому в компании не только разрешено, но и активно поощряется участие.
«Мы хотим, чтобы люди не просто соглашались с языком дизайна, но и
принимали его и двигали вперед», - Юрген Шпангл, руководитель отдела дизайна Atlassian.
В рекомендациях по дизайну Atlassian есть модель с открытым исходным кодом, в которой каждый может вносить свой вклад, а вклады управляются и курируются.
На BBC GEL предоставляет «идеальные платоновские» версии шаблонов, и тогда у каждого отдела есть своя реализация.
В этой главе мы рассмотрели несколько команд с разными подходами к проектированию систем. Вот как я бы разместил их на трех шкалах, представленных ранее.
Система Airbnb является строгой, модульной и централизованно организованной. Он действует через правила и процессы, которые строго соблюдаются. Существует много определенности и согласованности с такой системой.
Почти на противоположных концах весов у нас есть системы, подобные TED, которые настроены гораздо более свободно и где творческое направление распределено по всей команде. Эти системы обычно допускают больше экспериментов, тонкой настройки и чувствительности к контексту.
Где-то посередине между ними у нас есть такие команды, как FutureLearn. Как молодая и растущая компания, система проектирования в FutureLearn пошла по своим масштабам. Все началось как более централизованное и интегрированное, постепенно становясь более распределенным и более модульным. Правила системы также стали более строгими со временем, как только мы начали концентрироваться на последовательности.
Другой важный аспект - это, конечно, командная культура , которая неизбежно отражается в системе дизайна, которую они будут создавать. Как гласит закон Конвея:
«Организации, которые проектируют системы […], вынуждены производить проекты, которые являются копиями коммуникационных структур этих организаций». 7
Команда Sipgate сейчас перестраивает свою библиотеку шаблонов. Интересно не то, что они переключили свою модель с распределенной на централизованную, но чтобы заставить централизованную модель работать, они должны были сначала продемонстрировать компании, как будет выглядеть полная автономия. Сначала, энергичные и полные энтузиазма команды в Sipgate не могли представить, что их проекты «контролируются» кем-то другим. Но с такой автономной культурой, как у них, они поняли, что это именно то, что им нужно для поддержания целостности и единства своей системы.
Чтобы это работало, им пришлось внести несколько изменений в процесс проектирования и в то, как они сотрудничают. В настоящее время команда уделяет больше внимания общей методологии и подходу к проектированию, а не эффективной документации шаблонов. Для них это было не только изменение направления - это также культурный сдвиг.
Правильная система для вас - это не чужая система. Все, что работает для одной команды, может не работать для другой. Иногда мы думаем, что другие команды поняли это правильно и стремятся создать такую же систему, как Airbnb. Но у каждого подхода есть свои недостатки. Правильная система для вас - та, где вы можете управлять недостатками.
В основе каждой эффективной системы проектирования лежат не инструменты, а общие знания о том, что делает хороший дизайн и UX для вашей конкретной команды и вашего конкретного продукта. Если это знание ясно, все остальное последует.
-
1. http://smashed.by/flipboard
2. У бренда и креативной команды в Spotify, которая управляет кампаниями, есть простая система, которая позволяет очень гибко сочетать стили бренда. Таким образом, они могут создать целый ряд кампаний, которые вписываются в бренд Spotify.
3. Как мы обсуждали в главе 5, этот подход работает через тесное сотрудничество и обмен знаниями. Кристофер Александер называет похожую концепцию подходом «шаблонного языка» в «Вневременном пути строительства» .
4. https://style.eurostar.com/
5. Неофициальное интервью с Беном Скоттом, май 2017
6. В Airbnb процесс добавления нового модуля может занять до двух недель. Это одна из вещей, которую команда пытается улучшить.
7. Закон Конвея появился из наблюдения, сделанного в 1967 году Мелвином Конвеем, программистом и программистом.
В этой главе мы рассмотрим поиск поддержки для создания системы проектирования в вашей организации и планирования работы.
Как команда начинает думать о дизайне более систематически? Как правило, когда они замечают проблемы с их текущим рабочим процессом. Дизайнеры разочаровываются в том, что всегда решают одни и те же проблемы или не могут правильно реализовать свои проекты. Разработчики устали от индивидуального оформления каждого компонента и работы с грязной кодовой базой. Оба борются за соблюдение сроков и требований растущего продукта. Без общего языка проектирования и практики совместная работа затруднена.
Некоторые люди начинают вносить улучшения - стандартизировать кнопки, настраивать основной файл Sketch, создавать простую библиотеку существующих компонентов. Другие замечают преимущества и объединяют свои усилия. Команда может стандартизировать больше шаблонов, выровнять словарь дизайна, установить новые инструменты и процессы. После некоторых проб и ошибок они увидят улучшения в том, как функционирует их система. Эти первые инициативы содержат ценные уроки. Но, чтобы реально изменить ситуацию, недостаточно работать над системой проектирования в качестве побочного проекта. Вам нужна широкая поддержка - не только от ваших коллег, но и от старших заинтересованных сторон в бизнесе.
Получить бай-ин не всегда просто. Некоторые команды начинают с сбора примеров визуальных несоответствий по всему продукту. Изображение несовместимых кнопок может быть убедительным графическим изображением, но этого не всегда достаточно, чтобы генеральный директор или ваш менеджер увидели ценность предлагаемых вами изменений.
Чтобы получить поддержку от бизнеса, вам необходимо продемонстрировать, что эффективная система проектирования поможет быстрее и экономичнее решать бизнес-задачи . Другими словами, вы должны сделать экономическое обоснование для этого.
Иногда это помогает использовать знакомый язык в вашем поле. Если идея «комплексной системы дизайна» звучит слишком широкой и абстрактной для вашей аудитории, попробуйте представить ее как «модульный интерфейс». Модульность имеет много подтвержденных практических преимуществ, которые мы обсуждали в предыдущей главе. Пока это правильное направление для вас, эти преимущества могут быть продемонстрированы в отношении вашей команды и вашего продукта. Вот несколько примеров.
Естественно, повторное использование существующего элемента, а не его создание с нуля, происходит быстрее. Вы можете даже приблизительно определить, сколько времени это может сэкономить. В FutureLearn создание относительно простого пользовательского компонента в первый раз может занять около трех часов. Модульное построение одного и того же компонента (правильная структура, гибкость для различных вариантов использования, придумывание хорошего имени, добавление его в библиотеку шаблонов) может занять вдвое больше времени. Но когда тот же компонент используется снова, он почти бесплатен. В долгосрочной перспективе это может сэкономить много времени, если вы работаете так, чтобы подчеркнуть повторяемость выбора.
Даже на первый взгляд простые элементы, такие как кнопки, требуют времени и усилий для проектирования и сборки. Чтобы заставить старшие заинтересованные стороны понять ценность повторного использования компонентов, консультант системы проектирования и автор модульного веб-дизайна Натан Кертис использует историю о сложности кнопок. В нескольких слайдах он демонстрирует, как кнопки могут стоить сотни тысяч долларов на разработку и создание.
«Если на вашем предприятии 25 команд, каждый из которых делает пуговицы, то для того, чтобы иметь хорошие пуговицы, у вас будет 1 000 000 долларов». 1
- Натан Кертис
Количественная оценка и демонстрация издержек неэффективности - часто самый эффективный способ получить исполнительный бай-ин.
Раздутая и неэффективная система означает, что даже самые маленькие изменения требуют много времени и трудоемки. В своей статье « Создан для роста » 2 Марко Суарес из Etsy описал, как технические и дизайнерские долги замедляют работу их команды. Он поделился примером различных работ Джессики Харли по обновлению стиля кнопок на etsy.com. Удаленный код отображается красным, а код - зеленым. Очевидно, слишком много кода было затронуто, чтобы сделать простое визуальное изменение.
Файл diff для обновления стиля кнопок на etsy.com, где удаленный код отображается красным цветом, а код - зеленым.
Изменения не только требуют много времени, но иногда одни и те же изменения должны применяться в разных местах. И наоборот, повторно используемый шаблон будет обновляться автоматически везде, где используется этот шаблон. Это ускоряет обновление всего сайта.
В долгосрочной перспективе модули должны улучшаться по мере их использования. Различные команды предлагают разные варианты использования и решения для их удовлетворения. Благодаря совершенствованию отдельных компонентов вся система становится более надежной и простой в обслуживании. И чем меньше времени команда тратит на исправление ошибок и распутывание грязного кода, тем больше времени им приходится работать над вещами, которые приносят пользу их пользователям и бизнесу.
Если вы посетите кондитерскую и закажете ассортимент готовой выпечки, вы получите совершенно другое предложение от заказа торта на заказ. В FutureLearn менеджеры по продуктам понимают различные временные рамки для разработки функций, сделанных из существующих модулей, по сравнению с новыми. Создание страницы с использованием шаблонов из библиотеки обычно занимает несколько дней; новый дизайн может занять несколько недель. Поэтому, если нам нужно протестировать концепцию или опробовать новую функцию, иногда для быстрого ее выпуска используются существующие модули. Возможно, он не идеален, но дает команде время для тестирования, сбора отзывов и выработки лучшего решения.
Тобиас Риттербах отметил, что команды в Sipgate, которые используют свою новую библиотеку шаблонов, работают во много раз быстрее, чем те, которые этого не делают:
«Наличие библиотеки шаблонов для sipgate.de позволяет нам создавать страницы в 10–20 раз быстрее, чем для других сайтов продуктов, которые не подключены к библиотеке».
- Тобиас Риттербах, владелец опыта, Sipgate
Эти примеры показывают, что модульная система помогает удовлетворить потребности растущего продукта, позволяя командам быстрее создавать прототипы и отправлять функции.
При обосновании системы проектирования выигрышные аргументы, как правило, направлены на демонстрацию и количественную оценку стоимости неэффективности . Но, конечно, есть и другие важные преимущества, которые могут быть оценены в некоторых организациях.
Нередко компании оказываются в ситуации, когда их разные продукты (или иногда даже части одного и того же продукта) выглядят так, как будто они принадлежат разным брендам. Объединение растущего продукта или линейки продуктов под одним брендом требует эффективной системы дизайна.
Дизайн - это форма языка - через дизайн мы передаем мысленную модель продукта. Последовательное визуальное представление помогает людям быстрее освоить интерфейс и снизить когнитивную нагрузку, делая вещи знакомыми и предсказуемыми. Это помогает сделать интерфейс интуитивно понятным .
Создание согласованности похоже на выполнение небольших обещаний по всему интерфейсу (когда вы видите розовую кнопку, это всегда действие; кнопка «Отмена» всегда идет перед «Отправить»). Когда люди могут быть уверены в том, что произойдет, они могут положиться на продукт. Последовательность помогает построить доверие.
Общий язык имеет основополагающее значение для совместной работы, и именно это обеспечивает эффективная система проектирования. Он дает людям инструменты и процессы для совместного создания вещей. Они могут опираться на работу друг друга, а не воссоздавать одни и те же вещи с нуля. Даже после простого сбора компонентов в одном месте, дизайнеры Airbnb начали видеть улучшения в производительности.
«Мы собрали компоненты в основной файл Sketch. Через неделю или две мы начали видеть огромные скачки в производительности, используя библиотеку при итерации по проектам ». 3
- Karri Saarinen, Design Lead, Airbnb
Представление этих случаев способами, определенными для их ситуаций, помогло командам получить поддержку, в которой они нуждались. Использование тестового проекта для демонстрации преимуществ также может быть эффективным, как посоветовала дизайнер Лора Элизабет в одном из своих выступлений. 4
«Испытание системы проектирования в небольшом тестовом проекте позволяет увидеть влияние, которое она может оказать на вашу работу, и продемонстрировать, сколько времени вы экономите».
Не каждый может создать специальную команду системы разработки или формализовать свои планы сразу, но даже проведение одного спринта с парой преданных людей может быть полезной отправной точкой для демонстрации того, чего можно достичь. Успех этих первых шагов может быть использован для получения дополнительной поддержки позже.
Как мы видели в предыдущей главе, у каждой команды будут свои требования, и для них будут работать разные стратегии. Но вот несколько советов, которые были полезны для большинства людей, независимо от их ситуации.
Каковы основные результаты, которые вы надеетесь достичь с помощью этой работы? Наличие четких целей дает команде направление и мотивацию. Это помогает им организовать свое время и сбалансировать приоритеты. Цель должна включать несколько целей - конкретные измеримые шаги для ее достижения.
Если вы, как и я, видите системы проектирования в отношении шаблонов и общих практик , ваши цели могут это отражать. Например, один из них может быть ориентирован на интерфейс, а другой - на работу команды.
• Определить руководящие принципы проектирования.
• Определить и стандартизировать шаблоны многократного использования.
• Создать библиотеку шаблонов.
• Настройте мастер-файлы дизайна с современными шаблонами.
• Рефакторинг кода и интерфейсной архитектуры для поддержки модульного подхода.
• Настройте процессы обмена знаниями (посредством разговоров, совместной работы, сопряжения, обучения и т. Д.).
• Продвигать библиотеку шаблонов и поощрять ее использование во всей компании.
• Продвигать общий язык дизайна между командами и дисциплинами.
• Ввести в систему проектирования часть процесса индукции.
Цели могут быть разбиты на более мелкие задачи и истории. Чтобы спланировать, как ваши цели будут достигнуты с течением времени, на этом этапе также полезно создать простую дорожную карту для вашей системы проектирования. Это может быть сделано в программном обеспечении, таком как Trello, или даже на доске с заметками. Важно то, что дорожная карта дает коллективу общее понимание своих приоритетов и того, как система должна развиваться с течением времени. 5 В FutureLearn мы также интегрировали истории системы дизайна в основную дорожную карту продукта. Это помогло остальной части команды осознать работу, которую мы выполняли, и сбалансировать ее с другими приоритетами.
Наличие четких целей и этапов также помогает управлять ожиданиями в остальной части компании. Система проектирования - это долгосрочная инвестиция, ее стоимость постепенно увеличивается со временем. Важно, чтобы люди ожидали увидеть постепенные и устойчивые улучшения, а не быстрые и драматические.
По моим наблюдениям, команды, которые обнародовали часть своей работы над системами проектирования, имеют тенденцию прогрессировать быстрее, чем те, кто держал все в тайне. Дэн Джексон из Eurostar объяснил в интервью важность публикации своего руководства по стилю на раннем этапе, даже если оно не было идеальным. Знание того, что другие могли учиться на своей работе, обеспечило дополнительную мотивацию:
«Я хотел, чтобы руководство по стилю было публичным продуктом, которым мы гордимся. Другие люди могут смотреть на это и использовать его как ресурс. Это заставляет нас чувствовать, что мы должны идти в ногу ».
- Дэн Джексон, архитектор решений, Eurostar
Некоторые команды пишут короткие сообщения в блоге о своей системе по мере ее развития. Это особенно полезно, если вы описываете не только свои успехи, но и свои ошибки, камни преткновения и то, что вы сделаете иначе в следующий раз. Документирование вашего прогресса открытым и честным способом - это мощный способ помочь вашей команде учиться и сохранять мотивацию.
Это также делает прозрачной работу, проделанную за сценой. Постоянно писать и говорить о нашей системе проектирования в FutureLearn было очень важно, чтобы побудить большее количество людей понять ценность работы, которую мы выполняли.
Как мы видели в примере с Sipgate в предыдущей главе, команда может иметь современную библиотеку шаблонов, но она не будет столь же полезной без эффективного взаимодействия между группами. Чтобы ваша команда могла мыслить более систематически, необходимы эффективные методы обмена знаниями. Мы обсудили некоторые из них в главе 5 «Общий язык»:
• Настройте выделенный канал Slack для совместной работы по определению и названию шаблонов проектирования и для обсуждения вопросов, связанных с системой.
• Создайте шаблонную стену, чтобы сделать процесс открытым и прозрачным для остальной части компании и поощрять к участию больше людей.
• Ввести в систему проектирования часть процесса индукции.
• Организуйте регулярные встречи, чтобы держать всех на той же странице, что и ваша система.
• Поощрять сотрудничество не только внутри отдельных команд, но и между командами и дисциплинами . В частности, поощряйте людей, которые более осведомлены о системе проектирования, работать со всеми, чтобы у них была возможность поделиться своими знаниями и энтузиазмом с людьми, которые менее погружены в систему.
• Организовать семинары и учебные пособия, чтобы познакомить команду с изменениями по мере развития системы. В FutureLearn самые эффективные презентации имели формат «проблема - решение». Сначала мы обсудили текущие проблемы с людьми, а затем объяснили, как предлагаемые нами изменения помогут решить проблему. Например: «Текущая типография означает, что текст слишком мал на больших экранах и слишком велик на маленьких экранах; это влияет на опыт чтения; непонятно, какие заголовки использовать, слишком много стилей, которые создают несоответствия и так далее. Вот как новая типографская система решает эти проблемы ».
• Одна из партизанских тактик, которую применял Виталий Фридман и его команда, - каждый день посвящать компоненту интерфейса. У них был день карусели, день лайтбокса, день аккордеона и так далее. Каждый получит распечатку с подсветкой компонента и его вариантов, включая интерфейсный код и связанные с ним стили.
«Мы поставили его рядом с кухонной раковиной и в ванной комнате. Месяц спустя все помнят названия всех компонентов, включая уборщиков! »
- Виталий Фридман, главный редактор журнала Smashing Magazine
Работа над системой проектирования - это длительный процесс. Ваша команда может не видеть вознаграждения за то, что вы делаете в течение некоторого времени.
«Вы не всегда сразу получаете личное удовлетворение - вознаграждение приходит, когда вы видите, как другие люди используют модуль, который вы создали в своей работе, или когда кто-то комментирует, насколько полезной была информация для них».
- Jusna Begum, front- конечный разработчик, FutureLearn
Есть несколько вещей, которые вы можете сделать, чтобы поддержать моральный дух команды во время процесса.
Вместо того, чтобы разбираться с бесконечным списком задач, поставьте перед собой задачу выполнить основную часть работы за один раз , а затем продолжить работу в рамках текущей работы. В Atlassian первоначальный прогресс был достигнут благодаря всплескам дизайна двумя или тремя людьми. Мэтт Бонд, дизайнер продукта, который руководил первоначальной работой над Atlassian Design Guidelines (ADG), объяснил в одном из своих постов в блоге, что двухэтапный подход позволил команде быстро пройти начальные этапы и затем поддерживать динамику:
«Это была высокая производительность, благодаря которой за короткий промежуток времени было получено много новых образцов с завершением на 80%. Затем мы потратили бы следующую неделю или около того на то, чтобы посвятить небольшое количество времени доработке шаблона и разработке руководств и кода для включения в ADG ». 6
Для некоторых работ, таких как проведение аудита интерфейса или настройка библиотеки шаблонов, полезно привлечь всю команду (или представителей нескольких групп), по крайней мере, на начальных этапах. Это обеспечивает общее чувство собственности. Если это невозможно из-за других приоритетов, пусть небольшая группа выполнит работу и при необходимости привлечет других. В FutureLearn двое из нас (дизайнер и разработчик внешнего интерфейса) провели спринт, полностью сосредоточившись на системе, подключая других по мере необходимости, как только мы выяснили, как она должна работать.
Это также помогает планировать задачи таким образом, чтобы обеспечить максимальную пользу при минимальных усилиях . В FutureLearn нашей целью было сделать все компоненты живыми. Это означало, что код для модулей на веб-сайте и в библиотеке шаблонов должен быть одинаковым. Но для этого потребовался рефакторинг каждого модуля. По мере их рефакторинга мы добавляли их в библиотеку шаблонов, одну за другой. Это был мучительно медленный процесс, и команда начала терять мотивацию.
Затем мы поняли, что могли бы обеспечить ценность быстрее, добавляя все шаблоны за один раз и отображая их в виде снимков экрана вместо кода. Это позволило команде сразу начать использовать библиотеку шаблонов для справки. В последующие месяцы мы постепенно заменяли скриншоты живыми модулями и продолжали их рефакторинг. Если бы мы этого не сделали, вероятно, потребовался бы еще один год, чтобы все шаблоны были задокументированы.
Одним из наших первых экспериментов с модульностью в FutureLearn была попытка перепроектировать домашнюю страницу. Визуальный дизайнер создал модульные срезы, и затем мы провели семинар, на котором мы попытались организовать их в полные композиции. Это то, что мы думали (возможно, наивно), как выглядел модульный процесс проектирования.
Один из наших первых экспериментов с модульностью.
В итоге мы получили три проекта, которые в итоге стали полностью функциональными прототипами. Но даже если это было полезное упражнение, результат не был по-настоящему модульным:
• Модули не имели четкой цели. Различия между ними были в основном презентационными.
• Мы не определили и не назвали их.
• Мы не очень задумывались над тем, как их можно использовать повторно.
• Их роль в общей системе была неясной.
Опытные образцы никогда не делали это в производство. Но именно такие эксперименты помогли сделать наш процесс проектирования более систематическим. Пробуя разные вещи, мы поняли, что модульный дизайн - это гораздо больше, чем просто урезание интерфейса и сборка частей. Если ваша команда является новичком в этом, полезно сначала изучить, что такое модульное, сначала поэкспериментировав на стороннем проекте или на небольшом участке вашего продукта.
Опробовав несколько разных подходов, мы пришли к более структурированному командному упражнению для систематизации интерфейса. Следующие две главы подробно описывают это упражнение. В двух словах, он будет состоять из трех этапов:
1. Определите ключевые модели поведения или эстетические качества
2. Аудит существующих элементов
3. Определите шаблоны
Шаги немного отличаются для функциональных и перцептивных паттернов. При использовании функциональных шаблонов основное внимание будет уделяться поведению пользователей , определению отдельных модулей и присвоению им имен. Мы рассмотрим шаблоны восприятия в целом, сосредоточив внимание на ощущениях и эстетике , а также на общих принципах их совместной работы. Порядок вы делаете это не критично. Некоторые команды считают полезным сначала взглянуть на основополагающие стили, такие как типографика; другие начинают с основных функциональных модулей. Также возможно смотреть на оба одновременно параллельно.
В обоих случаях мы сначала рассматриваем общую картину, а затем разбиваем интерфейс на более мелкие части. Подобный подход помогает нам думать не только об отдельных модулях, но и о том, как они работают вместе , и как они помогают достичь цели продукта .
-
1. Из « А вы думали, что кнопки были легкими? Натаном Кертисом.
2. http://smashed.by/designforgrowth
3. См. « Создание системы проектирования Airbnb » Карри Сааринена.
4. См. « Продажа систем проектирования » Лоры Элизабет.
5. Для получения практических советов по созданию дорожных карт систем проектирования см. « Дорожные карты для систем проектирования » Натана Кертиса.
6. См. « Как мы разработали Atlassian Design Guidelines » Мэтта Бонда.
Упражнение в этой главе описывает подход к систематизации функциональных шаблонов, начиная с цели продукта.
В городе, где я живу, есть небольшой книжный магазин. Когда вы входите, вы видите несколько полок с книжными обложками. У некоторых есть небольшие рукописные заметки: отзывы людей, которые их читают. Даже если вы не знаете, что хотели бы прочитать, есть большая вероятность, что вы наткнетесь на что-нибудь интригующее. Как только вы это сделаете, есть тихая зона с диванами, чтобы просматривать книги за чашкой кофе. Вы можете решить купить что-то или нет, давления нет. Этос магазина - открытие и чтение; продажи кажутся вторичными. Его узоры - ноты, тихие зоны, диваны и журнальный столик - отражают это.
Точно так же цифровые продукты поощряют или обеспечивают определенное поведение. Подумайте, как Slack поддерживает более совместные способы работы по сравнению с электронной почтой или другими приложениями чата. Или подумайте, как Tinder продвигает случайные, свободные от обязательств отношения с помощью интерактивного взаимодействия. Продукты могут быть разработаны с учетом аналогичных целей и потребностей пользователя, в то же время поощряя совершенно другое поведение. Вот почему размышления о поведении могут быть полезны при соединении шаблонов с замыслом дизайна и идеалом продукта. 1
Намерение дизайна может быть представлено бесчисленными способами - образцы не должны быть визуальными. Они могут быть представлены в физических объектах (например, в интерьере книжного магазина) или могут быть прочитаны голосом. Изложение поведения помогает определить шаблоны таким образом, чтобы он был более устойчивым к будущему, потому что поведение не зависит от платформы.
Инвентаризации интерфейса 2 является популярным упражнением , чтобы начать систематизацию интерфейса. Это включает в себя создание снимков экрана различных элементов пользовательского интерфейса, а затем группирование похожих элементов.
Но хотя идея проста, это может быть сделано различными способами. Иногда кадастры фокусируются на визуальной согласованности интерфейса; например, убедившись, что все кнопки выглядят одинаково, все меню согласованы и т. д.
Основная цель процесса, описанного в этой главе, состоит не в том, чтобы учесть все визуальные несоответствия; это определить наиболее важные шаблоны проектирования и получить взаимопонимание в команде о том, как они должны работать в системе. Прохождение этого процесса даст вашей команде представление о том, какие области требуют большего внимания. Типичным результатом будет список элементов, которые должны быть стандартизированы, наряду с некоторыми набросками и идеями о том, как следует определять шаблоны.
В то время как визуальный обычно копируют группы вещей по внешнему виду и типу (кнопки, вкладки элементы управления и так далее), в следующем упражнении вы можете в конечном итоге с вещами в одной и той же группе , что выглядят по- разному, потому что вы группируя их по назначению ( поведения, которые они предназначены для поощрения или включения).
В целевом инвентаре вещи в одной и той же категории могут выглядеть иначе, потому что они сгруппированы по назначению, а не по внешнему виду.
Это означает, что вместо того, чтобы сосредоточиться на том, чтобы все кнопки выглядели единообразно, мы сначала попытаемся понять, когда использовать кнопку определенного типа, когда использовать ссылку вместо кнопки, когда вообще не использовать кнопку, и вместо этого нажать непосредственно на объект. Конечно, в процессе этого мы улучшим визуальную согласованность, но это не будет центром внимания.
Чтобы быть наиболее эффективным, этот процесс должен быть запущен после того, как основополагающая работа UX - исследование пользователей, контент-стратегия, информационная архитектура, направление дизайна - была разработана. Если у дизайна есть фундаментальные недостатки и проблемы с юзабилити, они будут отвлекающими и контрпродуктивными для решения. По тем же причинам, если ваш интерфейс собирается претерпеть существенные изменения, лучше сначала получить четкое представление о новом направлении дизайна.
Наличие разных точек зрения поможет вам быть более объективным и учитывать больше вариантов использования. Важно, чтобы в работе принимали участие дизайнеры и внешние разработчики, но в идеале должны быть привлечены внутренний разработчик, человек с опытом работы с контентом и менеджер по продукту. Идеальный размер группы составляет около 4–8 человек. Если необходимо привлечь большую группу, рассмотрите возможность выполнения начального упражнения с несколькими представителями из разных дисциплин, а затем проведите последующие занятия, чтобы обсудить больше людей.
Определите ключевые экраны и потоки пользователей, которые являются абсолютно фундаментальными для вашего продукта, те, без которых продукт не может существовать. Как правило, достаточно 10–12 экранов, иногда меньше. Это могут быть макеты дизайна или скриншоты существующего интерфейса.
Допустим, вы работаете над сайтом публичной библиотеки. Цель веб-сайта - расширить возможности работы с физической библиотекой, возможно, убедившись, что читатели могут зарезервировать книги заранее и, таким образом, избегать очередей и ожидания материалов, когда они окажутся в библиотеке. Ключевые экраны помогают достичь этой цели, позволяя вам находить конкретные книги, открывать новые книги, резервировать материалы для сбора и загружать материалы. Конечно, веб-сайт библиотеки может многое другое: события и выставки, членство, онлайн-коллекции. В то время как мы должны принять к сведению другие области, обычно каждое отдельное представление не требуется, чтобы начать.
Распечатайте две копии каждого экрана. Положите первый набор на стену в порядке типичного путешествия пользователя. Второй набор будет использоваться для вырезания узоров и их группировки. Вы будете постоянно переходить от системы в целом к отдельным моделям на протяжении всего упражнения. Наличие двух комплектов распечаток поможет вам сосредоточиться как на деталях, так и на более крупном изображении, не теряя при этом контекста, откуда берутся шаблоны, когда вы их вырезали.
Вам также понадобятся ножницы, маркеры, заметки, а также много места на стене и на столе для работы.
Начните с определения ключевых потребностей пользователей и поведения, которые вы хотите поддерживать в каждом сегменте пути пользователя. Для небольшого приложения с несколькими экранами вы будете смотреть на отдельные экраны или разные состояния на одном экране. Для более крупных продуктов это помогает сгруппировать страницы в сегменты пользовательского пути.
Чтобы вернуться к примеру с веб-сайтом публичной библиотеки, вы можете сгруппировать некоторые из своих страниц на основе следующих действий:
• Открытие. Поощряйте людей находить книги, которые им могут быть интересны. Чтобы провести аналогию с книжным магазином, эта область похожа на подбор персонала или полки с новыми книжными витринами. Если кто-то не знает, что он ищет, он может быть вдохновлен выбором на дисплее.
• Каталог. Найдите конкретные книги. Поиск по каталогу - это все равно, что подойти к сотруднику и сделать запрос.
• Список пожеланий. Разрешить людям просматривать и управлять своими избранными книгами. В физическом магазине вы отложите некоторые книги в сторону, чтобы потом решить, какие из них оставить. 3
Некоторые из основных экранов сгруппированы по поведению, которое они поддерживают на протяжении всего пути пользователя. 4
Обратите внимание на страницы с противоречивым поведением: ситуации, когда мы призываем людей просматривать новые книги, загружать что-то, подписываться на новостную рассылку и проверять последние события одновременно. Даже если экран поддерживает несколько вариантов поведения, наиболее важные действия должны быть четкими и не противоречить друг другу. При работе с несколькими видами поведения, в первую очередь сосредоточьтесь на путешествиях основных пользователей и наиболее важных поведениях. В этом примере: обнаружение, поиск и резервирование книг.
Слова, которые мы выбираем, имеют значение. Они влияют на то, как мы думаем. В течение нескольких месяцев команда, в которой я работал в FutureLearn, имела «удержание» в качестве нашей метрики. Он был направлен на то, чтобы побудить больше людей продолжать обучение на курсе после его начала. Проектирование для удержания было сложно. Также не было ясно, как именно удержание принесло пользу нашим пользователям. Если бы метрика была названа «вовлеченность», это могло бы привести к различным результатам проектирования. И, возможно, даже больше, если бы метрика была сосредоточена на качестве и удовлетворенности обучением, а не временем, проведенным на сайте. (Кто-то мог бы провести полчаса в FutureLearn и узнать, что им нужно, но это не засчитывается как успех).
Поведение должно быть осмысленным и работать с точки зрения пользователя, а также бизнеса. 5 «Продвижение» книг приносит пользу только библиотеке, но «Открытие» новых книг также имеет ценность для читателя. Это делает его лучшим выбором языка и может повлиять на выбор отображаемых книг, а также на то, как они отображаются.
После того, как вы определите поведение высокого уровня, разбейте их на более конкретные действия, которые влияют на это поведение. Запишите их рядом с каждым экраном. Например, действия, которые поддерживают «Обнаружение книг»:
• Сканирование на любые вдохновляющие или интересные книги.
• Уточнить список рекомендуемых книг.
• Контроль, как представлен список.
• Просмотр и узнать о книге.
• Сделайте выбор книг, которые вам могут понравиться.
• Шорт-лист и резервные книги.
Действия влияют на поведение более высокого уровня.
Вы можете заметить, что некоторые действия повторяются по всему интерфейсу. Но элементы, которые их представляют, не всегда одинаковы. В некоторых случаях мы уточняем список книг, нажимая на вкладки; на других, выбрав пункт из меню. Чтобы выявить эти несоответствия, мы можем провести аудит существующих элементов.
Принимая одно поведение за раз, просмотрите все страницы, чтобы найти элементы, которые его поддерживают. Например, чтобы «просмотреть книгу», мы могли бы использовать разные элементы на промо-страницах, в результатах поиска в каталоге и в списке пожеланий.
Вырежьте связанные элементы, используя второй набор распечаток. Разложите их по группам и обозначьте каждую группу: «Просмотреть книгу», «Уточнить список» и т. Д. Они кандидаты, которые должны быть определены как шаблоны. Элементы должны быть сгруппированы с одинаковым уровнем детализации , поэтому у вас не будет модуля «Список книг» и кнопки «Резерв» в одной группе.
Группы элементов: кандидаты для определения в качестве шаблонов.
Теперь, когда у вас есть группы элементов, решите, как обращаться с элементами в каждой группе. Должны ли они быть объединены в один шаблон или храниться отдельно? Как правило, это решается на индивидуальной основе. Но есть два метода, которые я считаю особенно полезными: размещение шаблона в масштабе специфики и составление схемы его содержимого.
Один и тот же шаблон может быть определен как более конкретный или более общий. Скажем, нам нужно показывать события и выставки на сайте библиотеки. Если мы определим их как два отдельных шаблона, мы можем сделать каждый из них более конкретным. С другой стороны, объединение их в нечто вроде «блока контента» сделало бы шаблон более общим.
Специфическая шкала.
Хотя это кажется простой концепцией, определение уровня специфичности - одна из самых хитрых вещей в модульном дизайне. Чем конкретнее что-то, тем меньше его можно использовать повторно. И наоборот, чтобы сделать что-то более повторно используемым, вам также нужно сделать его более общим. С более конкретными частями, становится все труднее поддерживать и поддерживать согласованность. Но слишком много общих модулей приводят к общим проектам. Как и во многих вещах, нет правильного способа определения шаблонов, и все зависит от того, чего мы пытаемся достичь.
Хотим ли мы, чтобы посетители сайта воспринимали выставки иначе, чем события? Есть ли что-то о событиях, которые могут противоречить дизайну выставок? Если это так, мы должны рассмотреть их разделение. Например:
• Дизайн выставочного модуля может быть сосредоточен вокруг изображения искусства. Так как выставки уникальны, они могут иметь собственные названия, которые дополняют искусство, создавая ощущение постера. Дату можно установить более мелким шрифтом и расположить в углу, чтобы она не отвлекала от постера.
• События проще. Мы могли бы сосредоточить дизайн вокруг выдающейся даты и иконы этого события.
Если нет причин различать эти два типа, мы должны объединить их в один шаблон: что делать в библиотеке. Это сделает шаблон более общим, потому что он должен работать в обоих случаях. Но это также будет означать, что каждое изменение, которое мы вносим в события, будет относиться к выставкам. Последовательность будет легче достичь, но за счет гибкости.
Еще один инструмент, который я считаю полезным, - это отображение структуры содержимого шаблона. Мы кратко рассмотрели это в главе 4 о функциональных шаблонах. Вот напоминание о том, что это включает в себя:
1. Перечислите основные слоты контента, которые должны быть эффективными для модуля. Может ли этот модуль функционировать без изображения или изображение является необходимым для его назначения? Всегда ли необходим ярлык? Отметьте необязательные элементы.
2. Определите иерархию элементов и определите, как они должны быть сгруппированы: значок является частью ключевой информации или частью изображения?
3. Сделайте наброски, чтобы визуализировать структуру. Один и тот же шаблон может быть представлен бесчисленными способами, а наброски помогают найти оптимальный дизайн.
Как правило, элементы, которые могут быть объединены в один шаблон, имеют общую структуру. С другой стороны, если вы изо всех сил пытаетесь объединить структуры нескольких элементов, не ставя под угрозу их назначение, это свидетельствует о том, что их не следует объединять.
Иногда элементы имеют схожую структуру, но из-за контекста или нашего замысла дизайна они должны выглядеть или вести себя по-разному. В этом случае мы можем создать варианты . Вариант - это модифицированная версия того же шаблона.
Снова зайдите на сайт библиотеки. Скажем, вы попали с этими предметами в группу «Просмотр книги».
Сгруппированные элементы книги: кандидаты для определения в качестве шаблонов.
Вы можете решить, что элементы A и B имеют одну и ту же цель: они оба отображаются в списках и позволяют людям просматривать книгу и узнавать о ней. Они также имеют одинаковую структуру контента:
Структура контента для предмета книги.
Хотя действия и миниатюра отсутствуют в элементе B, очевидных причин для этого нет. Миниатюры полезны для сканирования книг, и вы сможете зарезервировать их, не выходя из списка желаний.
С другой стороны, пункты D и E различны. Их основная цель заключается в предоставлении вдохновения и демонстрации новых и заслуживающих внимания предметов. Если мы нарисуем их структуру, это может выглядеть так:
Структура контента для книжной витрины.
Вы можете проверить это, подумав о том, как вы ожидаете изменений. Спросите себя: если я изменю этот модуль, я хочу, чтобы другие изменились таким же образом ? Например, хотя «обложка» и «миниатюра» выглядят одинаково, мы могли бы решить относиться к ним как к совершенно другим вещам. Возможно, дизайн страниц открытий включает в себя определенные взаимодействия и анимацию, чтобы привлечь внимание к демонстрируемым книгам. Мы не хотим, чтобы тот же эффект применялся к стандартному элементу книги в списке.
Теперь давайте посмотрим на пункт C. Он похож на A и B и имеет общую структуру контента. Но он более заметен из-за своего контекста: открытия и демонстрации частей сайта. Он также более подробный и содержит больше информации, чем элемент книги в списке. В этой ситуации имеет смысл сделать этот элемент вариантом элемента книги.
С вариантами у вас обычно будет шаблон по умолчанию с основными стилями. Варианты будут иметь дополнительные стили. Важно знать, какие функции являются ключевыми в шаблоне, а какие специфичны для вариантов. Затем вы можете предсказать, как изменение одного из них повлияет на другие.
В приведенном выше примере некоторые элементы в базовом шаблоне по умолчанию различаются по масштабу, поэтому шаблон выглядит совершенно иначе:
• большое название
• большой эскиз
• более просторная планировка
Мы знаем, что можем изменить заголовок, не затрагивая элемент книги, но если мы, например, изменим стиль автора, это изменение будет применяться в обоих местах.
Рассмотрение взаимосвязи между структурой контента и стилями может увеличить повторное использование большего количества шаблонов. Попробуйте просмотреть все ваши шаблоны и сопоставьте основное содержимое («название книги») с именами стилей («большое название», «небольшое название», «небольшие метаданные»). Точно так же это было бы хорошим местом, чтобы начать смотреть на количество символов или изменения размера изображения. Шаблон будет работать с большим количеством типов контента, если стандартизированы разные размеры.
Как мы обсуждали в главе 5 об общем языке, имена влияют на то, как используются шаблоны. Правильно выбранное имя - это мощный инструмент для формирования вашей системы дизайна.
Попробуйте найти имя, которое отражает положение шаблона на шкале специфичности. Если вы сомневаетесь, начните с более конкретного имени. Например, мы привыкли рассматривать процесс обучения на курсе FutureLearn как особый опыт, который поставляется с собственным набором модулей, специфичных для данной области курса.
Вкладки курса в области обзора курса на FutureLearn.
В этом случае имело смысл использовать название «Вкладки курса» - мы не хотели использовать их где-либо еще. Это имя также сигнализировало остальным членам команды, что они не были какими-то общими вкладками - они были специфичны для области курса. Позже мы решили, что этот модуль может быть полезен и в других местах, и изменили имя на «Вкладки страниц». Новое имя было более общим и снова сообщило команде, что теперь оно доступно для использования в других областях.
Иногда модули именуются во внешнем интерфейсе, но присвоение имен также является решением UX и должно приниматься совместно на этапе проектирования. Имена должны учитывать тип контента, но не должны основываться исключительно на контенте. Эффективные имена направляют использование и уменьшают вероятность дублирования шаблонов.
Как только вы сгруппируете автономные части, повторите процесс с другими элементами. Как правило, это включает в себя несколько сеансов: один для обсуждения поведения пользователя в целом, а отдельный - для рассмотрения более детальных шаблонов, таких как:
• кнопки и ссылки
• заголовки
• списки
• вкладки и меню
• переключатели, переключатели и флажки
• сообщения обратной связи
• навигация
• изображения
• значки
Если у вас есть элементы с похожими целями, подумайте о них относительно друг друга, а не независимо. Чем кнопки отличаются от ссылок? Чем навигация по вкладкам отличается от меню списка? Чем выпадающий список отличается от набора кнопок? Чем флажок отличается от переключателя? 6
Вот некоторые моменты, которые следует учитывать при проверке ссылок и кнопок .
Традиционно в веб-разработке ссылки и кнопки разные. Ссылка переходит пользователь от текущей страницы. Кнопка отправляет действие и переключает что-то в интерфейсе. 7 Но на практике нелегко принимать проектные решения, основываясь только на этом критерии.
Предположим, у нас есть пункт с кнопкой «Просмотреть книгу». Нажатие на кнопку расширяет модуль, раскрывая больше информации о книге. Теперь представьте, что одна и та же информация открывается на другой странице. Значит ли это, что действие должно быть представлено в виде ссылки?
Как и во многих других вещах, путаница часто заключается в языке. Некоторые люди (разработчики часто) определяют кнопку как триггер, который отправляет данные. Таким образом, ссылка, помеченная как кнопка, не будет считаться настоящей кнопкой для них. Другие (часто дизайнеры) рассматривают кнопку как отдельный, самостоятельный призыв к действию. Они будут называть отдельный элемент «Просмотр книги» кнопкой, даже если он помечен как ссылка.
Различные системы также подходят к этому по-разному. В IBM Carbon 8 ссылки являются навигационным элементом. Кнопки используются только в том случае, если действие пользователя изменит или манипулирует данными. В Shopify Polaris 9 , с другой стороны, кнопки могут представлять любой тип действия, включая навигацию. Ссылки используются как для встроенных действий, так и для навигации.
Использование ссылок в IBM Carbon.
Для меня наиболее важным аспектом является последовательное выражение цели . Пользователи (как те, кто обращается к интерфейсу визуально, так и с помощью программ чтения с экрана) должны знать, чего ожидать. Если кнопки всегда используются только для отправки данных, было бы странно иметь одну ситуацию, когда они ведут себя как ссылки. Но если в интерфейсе постоянно используются ссылки, стилизованные под кнопки (например, для отдельных призывов к действию), тогда это будет уместно.
Чтобы избежать путаницы и неправильного использования этих основных элементов, важно согласовать их определения. Каковы общие значения «кнопка» и «ссылка» в вашей команде? Каковы основные рекомендации по их использованию?
Одно из самых простых и наиболее эффективных отличий, с которыми я столкнулся, было предложено Хейдоном Пикерингом в « Инклюзивных шаблонах дизайна» 10 . Идея состоит в том, чтобы различать ссылки и призывы к действию (CTA), а не кнопки и ссылки. Важное отдельное действие может быть представлено в виде кнопки, но может быть помечено либо как ссылка, либо как кнопка, в зависимости от взаимодействия. Вопрос о том, является ли это ссылкой или кнопкой, зависит от вариантов - в первую очередь это CTA.
Пример классификации кнопок и ссылок. Кроме того, это помогает сделать тонкую разницу в стиле CTA, чтобы показать разницу во взаимодействии.
Если действие происходит на текущей странице, используйте кнопку CTA. Если действие уводит пользователя из текущего контекста, используйте ссылку CTA. Призывы к действию отличаются от стандартных ссылок, которые представляют собой пути к необязательной информации и обычно встраиваются в контент: основной текст, заголовки, изображения.
Подобное разграничение позволяет удовлетворить потребности проекта в том, чтобы держать важные призывы к действию заметными, в то же время сохраняя код простым и доступным.
Большинство интерфейсов имеют эквиваленты первичных и вторичных кнопок. Но что именно означает «первичный»? Означает ли это самое важное действие в контексте всего интерфейса, определенного экрана или раздела? Например, должна ли кнопка «Резервировать книгу» всегда иметь определенный стиль из-за важности действия на веб-сайте библиотеки?
В системе проектирования Marvel 11 «плоские» кнопки используются для обозначения «необходимых или обязательных действий»; «Призрачные» кнопки используются для обозначения «необязательных, редких или тонких действий». Плоские кнопки могут использоваться рядом друг с другом, когда действия одинаково важны. Мне нравится это различие, потому что оно простое, понятное и соответствует назначению кнопки.
Но для более сложных интерфейсов с большим количеством кнопок сложно сохранить их функции такими специфичными. Вам также может понадобиться посмотреть, как кнопки связаны друг с другом при совместном использовании. В системе 12 Atlassian и Polaris 13 от Shopify первичные кнопки представляют «самые важные действия в любом опыте» и поэтому должны появляться только один раз на экране.
Некоторые из типов кнопок в Polaris расположены по уровню значимости.
У них есть «базовая» кнопка, используемая по умолчанию. Другие стили используются только «если кнопка требует большей или меньшей важности». Подумайте об этом так: если интерфейс был прочитан голосом, какое действие было бы прочитано первым? Какие действия будут объявлены более громко или с другой интонацией?
Всегда будут особые случаи. В примере веб-сайта библиотеки кнопка «Резерв» может обрабатываться по-разному. Это может включать состояния, специфичные для действия; например, его ярлык может измениться на «Отменить бронирование», если книга еще не была собрана.
Кнопка FutureLearn «Progress toggle» также может рассматриваться как особый случай. Он используется только на этапах обучения, чтобы указать, завершен ли этап. Оживленная анимация и всплывающая пиктограмма призваны придать ей праздничный вид. Это не предназначено для чего-либо еще.
Кнопка переключения прогресса.
Возможно, именно из-за этой специфики мы изо всех сил пытались назвать его - мы пытались придумать общее имя («Progress toggle»), хотя на самом деле у него могло быть имя, специфичное для его функции - даже «Mark complete» могло быть более подходящее и запоминающееся имя в этом случае.
И кнопка «Переключение прогресса», и кнопка «Резервировать» библиотеки - это то, что мы хотели бы сделать более запоминающимися. Это ключевые функции бренда и, возможно, возможности для фирменных моментов. Такие же особые случаи, как этот, должны быть случайными, так что оба они кажутся различными, но также и общие правила шаблона сохраняются.
В этой главе мы рассмотрели систематизацию небольшого раздела интерфейса. После выполнения этого процесса в вашей команде вы будете лучше понимать свою систему и области, которые требуют внимания.
На следующих этапах команды могут погрузиться в код и Sketch, чтобы завершить разработку проектов для шаблонов - убедиться, что он работает для всех необходимых сценариев использования, определения состояний и поведения, рефакторинга кода.
При первом выполнении этого упражнения вы можете быть поражены количеством элементов и шаблонов. Вам не нужно делать все это за один раз. Начните с основных паттернов, имеющих фундаментальное значение для опыта, затем перейдите в другую область. Самое главное, это упражнение должно выполняться регулярно по мере развития вашей системы. Это немного похоже на садоводство - чем дольше вы его оставляете, тем труднее его привести в хорошую форму.
Теперь давайте посмотрим на модели восприятия.
-
1. Точно так же шаблоны проектирования могут использоваться для создания поведения, которое привлекает внимание пользователей или манипулирует людьми, чтобы тратить время и деньги на то, о чем они потом пожалеют ( https://darkpatterns.org/ ). Осознание поведения может помочь убедиться, что интересы пользователя всегда лежат в основе дизайна.
2. http://smashed.by/interfaceinventory
3. Кроме того, если у вас слишком много страниц в одних и тех же сегментах, поддерживающих одинаковое поведение, это указывает на то, что вашей информационной архитектуре может потребоваться работа.
4. Иллюстративные страницы взяты с веб-сайта Нью-Йоркской публичной библиотеки .
5. Успешные компании объединяют цели пользователей с бизнес-целями. Если вы действительно изо всех сил пытаетесь соединить их вместе, у вашего продукта могут быть более глубокие проблемы, которые система дизайна не сможет решить.
6. Существуют общие рекомендации и рекомендации (отличный ресурс см. В разделе « Разработка веб-интерфейсов » Билла Скотта и Терезы Нил; « Разработка интерфейсов: шаблоны для эффективного проектирования взаимодействия» Дженифер Тидуэлл), но некоторые вещи могут быть специфическими для вашей ситуации. Даже если они общеизвестны для некоторых людей, стоит их озвучить, чтобы остальная часть команды могла учиться.
7. См. « Ссылки против кнопок в современных веб-приложениях » Марси Саттон и « Правильное использование кнопок и ссылок » Деннис Лембре.
8. http://smashed.by/ibmcarbon
10. http://smashed.by/inclusivedesignpatterns
Упражнение в этой главе описывает, как определить шаблоны восприятия и интегрировать их в систему.
Что-то недавно привлекло мое внимание в двух продуктах, которыми я пользовался, - дизайн аккордеонных элементов управления. В обоих интерфейсах аккордеоны выглядели одинаково и имели одинаковую (стандартную) функциональность: расширение и свертывание разделов контента. Оба будут считаться «эстетически приятными» для большинства людей. Но почему-то один из них не был таким же крепким, как другой. Состояние наведения было слишком тонким, переходы были немного медленными, выбранное состояние не выделялось, и, казалось, не было достаточного контраста между заголовками и основной копией.
Дизайн другого аккордеона, казалось, правильно продумал все детали. Мало того, одни и те же шаблоны - цвет, переходы, контрастность, типографика - были применены по всему интерфейсу, что помогло сделать его прочным и хорошо сложенным. Хотя эти два продукта имели одинаковую полезность, один из них давал представление о качестве и надежности, а другой - хрупкий и хрупкий.
Иногда мы думаем, что если красота - это не то, к чему мы стремимся, нам не нужно придавать эстетику никакого значения: «Это просто функциональный инструмент. Это не должно быть похоже ни на что конкретное ». Но тогда мы упускаем ключевую возможность повлиять на восприятие продукта. Важно, конечно, не сами стили, а их эффект . Функциональный инструмент должен быть полезным и удобным, но он также должен быть простым, безопасным и надежным.
Чтобы влиять на восприятие надежным и масштабируемым образом, мы должны знать о паттернах, которые его создают.
Наиболее очевидный способ восприятия цвета, типографики, интервалов и других стилей заключается в их свойствах: значениях цвета, размерах текста, единицах измерения.
Возьмите цвет, например. Во многих библиотеках шаблонов это представлено набором значений.
Цветовые переменные Pivotal 1 демонстрируют общий подход к представлению информации о цвете.
Но даже со стандартизированной цветовой палитрой все еще есть много возможностей для интерпретации. Что представляют собой значения? Какой вариант зеленого цвета вы должны использовать? Как цвета работают вместе?
Для энтузиастов систем проектирования вот противоречивая мысль: небольшие отклонения в цвете не являются проблемой. Фактически, наличие двадцати оттенков синего не является проблемой, если синий цвет имеет постоянное значение во всем интерфейсе. Но если синие представляют ссылки в некоторых частях сайта, а в других есть синие заголовки, на которые пользователи не могут кликать, это может вызвать проблемы с юзабилити. Набор общих цветов не достаточен - вам также нужно совместно использовать цвета в контексте продукта.
Аналогично, только четко определенная типографская шкала не сделает вашу типографику более сплоченной. Даже после того, как мы стандартизировали все размеры текста в FutureLearn и ввели единую шкалу типов, заголовки все еще не всегда использовались единообразно - дизайнеры и разработчики не были уверены, какой размер выбрать из шкалы. Совместное использование типографики требовало четких руководящих принципов и схем использования, понятных каждому.
Типографская шкала на FutureLearn послужила основой для всей типографии.
Как мы определяем стили таким образом, чтобы сообщать об их назначении и поощрять их последовательное использование? Как и прежде, мы начнем с более высокого уровня, а затем углубимся в детали. С помощью функциональных шаблонов мы сначала посмотрели на поведение пользователей. С шаблонами восприятия мы начнем с эстетических качеств.
Каждый интерфейс имеет определенный вид, даже если он представлен только через текст или голос. Наиболее эффективные стили не применяются на поверхности, а развиваются вместе с продуктом - они будут связаны с его идеями и основными принципами дизайна («Вечный, а не передовой», «Направление над выбором»). Подумайте, как воплощены эти качества. Что заставляет ваш продукт чувствовать себя вне времени, или утилитарным, или традиционным, или ультрасовременным, или теплым, или крепким?
Если дизайн был в течение некоторого времени, закрепить эти шаблоны не всегда легко. Мы видели (с примерами FutureLearn в главе 4), что по мере роста вашего продукта его основная эстетика может измениться. Когда вы посмотрите на стили, вы можете заметить, что некоторые из них более эффективны, чем другие, и более тесно связаны с вашим брендом.
Шаблоны подписей 2 - полезное начальное упражнение, позволяющее всей команде (не только дизайнерам) попасть на одну страницу, особенно если они не привыкли думать о шаблонах восприятия. Попросите каждого человека записать самые запоминающиеся и четкие элементы, которые заставляют ваш продукт чувствовать себя определенным образом.
• Какие стили и оттенки приходят на ум, когда люди думают о вашем продукте?
• Как ваши пользователи описывают эстетику?
• Есть ли какие-то моменты, часто вызываемые в отзывах пользователей («Этот розовый тик всегда заставляет меня улыбаться»)?
Также полезно определить места или примеры, где дизайн не по бренду; например, «Маленькие тонкие анимации, а не быстрые, оживленные».
Подумайте не только о свойствах, но и о принципах высокого уровня, комбинациях различных элементов и отношениях между ними. Например, вместо простого перечисления цветов, опишите пропорции между ними: «В основном белый с розовым и синим акцентами». Включите примеры типичного представления рисунка. Вот как может выглядеть ваш список:
Заметки из шаблонов подписей для FutureLearn.
Я считаю, что сбор шаблонов подписей в команде может обеспечить руководство и вдохновение для всего процесса. Смотря на фигуры, скажем, если круги являются отличительной чертой в вашем интерфейсе, вы можете спросить, почему вы используете квадраты в некоторых случаях.
Опираясь на упражнение с шаблонами подписей, вы должны составить собственный список отдельных стилей для проработки. Вот некоторые из типов вещей, которые могут появиться в вашем списке:
• цвет
• интерактивные состояния
• анимация
• типография
• расстояние
• стили иконографии
• формы и границы
• иллюстрации
• фотография
• голос и тон
• звуки и звуковые сигналы
С каждым индивидуальным стилем, на котором вы хотите сосредоточиться, существует простой процесс их систематизации.
1. Начните с цели.
2. Соберите и сгруппируйте существующие элементы.
3. Определите шаблоны и строительные блоки.
4. Согласуйте руководящие принципы.
Вы не сможете пройти все стили за один раз. Каждый из них будет нуждаться в своем собственном инвентаре (и, возможно, в спринте или дольше, чтобы потом интегрировать изменения).
По мере их прохождения будут совпадать: между типографикой и пространством, цветом и текстом, формами и границами, границами и иконографией. Это хорошо, потому что вы можете использовать свойства, которые вы определили ранее, и увидеть, как они связаны друг с другом. Например, определенные вами цвета будут использоваться в интерактивных состояниях; интерактивные состояния будут использоваться в анимации. Глядя на типографику и интервалы, вы можете видеть, как размер текста влияет на интервалы вокруг него.
Цель первого шага - сделать использование цвета более последовательным. Для этого мы начнем с перечисления ролей, которые цвет играет в вашем интерфейсе.
Формулировка важна. То, как мы формулируем цель, не должно быть расплывчатым и очевидным. Подобное утверждение правительства Канады Web Experience Toolkit 3 не будет особенно полезным: «Используйте цвет в качестве элемента презентации для декоративных целей или для передачи информации».
Быть конкретной. Например, цвет можно использовать для:
• Отображение различных типов и иерархии текста (тело, заголовки, цитаты).
• Выделите ссылки и действия (основные CTA, поддерживающие CTA, ссылки).
• Привлекайте внимание к сообщениям и различайте их (подтверждение, предупреждение).
• Разделяйте контент или создавайте акценты (фоны, границы).
• Различать типы данных (в диаграммах, графиках).
Роли, которые вы определяете, будут определять категории вашего инвентаря.
Несмотря на то, что я предпочитаю бумажные запасы из-за их осязаемости, сложно проверить стили, вырезав их на бумаге. Документ Google 4 может работать лучше, и поэтому может Keynote, Powerpoint или эскиз - все , что вам подходит.
Установите пустой документ с категориями. По мере прохождения аудита вы можете корректировать заголовки или добавлять новые, но это помогает не начинать с пустой страницы.
Пример исходных категорий для проверки цветов в документе Google.
Для каждой категории добавьте:
• Тип
Укажите тип объекта, к которому применяется цвет, например, призыв к действию, заголовок, сообщение обратной связи и т. Д.
• Пример
Добавить снимок экрана элемента, чтобы показать, где используется цвет.
• Значение
Укажите шестнадцатеричное значение.
• Чувство
Если целью цвета является создание определенного настроения или ощущения, укажите это.
Вы получите список цветовых экземпляров, сгруппированных по назначению. Вот пример аудита ссылок и кнопок в интерфейсе публичной библиотеки. Таким же образом я собирал и группировал цвета текста, сообщения обратной связи, фоны, границы и так далее.
Аудит ссылок и кнопок, проведенный в Google doc.
Некоторые цвета будут иметь определенное чувство, связанное с ними. В интерфейсе TED черные заголовки используются для создания более кинематографического (и менее информативного) ощущения. На FutureLearn полный градиент от синего до желтого помогает создать праздничное настроение, когда учащийся завершает этап.
Использование полного градиента на FutureLearn для празднования вехи.
Если есть определенные эмоциональные качества, которые этот цвет должен привнести в ваш продукт, важно уловить это. Неправильное использование может ослабить цель, для которой предназначались цвета. Например, использование полного градиента в рекламных модулях на FutureLearn ослабит его связь с празднованием.
Далее вы можете определить шаблоны использования, основываясь на назначении цвета (и почувствовать, если это уместно). Когда вы используете синие ссылки, а когда серые? В чем смысл красных призывов к действию? Почему некоторые фоны серые, а другие ярко окрашены? В чем разница между черным и красным заголовками?
Пока не беспокойтесь о точных шестнадцатеричных значениях. Важно то, что вы согласны с использованием цвета через интерфейс. Вот пример того, как шаблоны могут быть определены для ссылок и кнопок.
Как определить цветовые схемы для ссылок и кнопок для сайта библиотеки.
Рассмотрение цели в первую очередь означает, что вы не только настраиваете вариации одного и того же цвета, но иногда меняете способ использования цвета. На сайте библиотеки, поскольку некоторые интерактивные элементы имеют красный цвет, мы ожидаем, что все красные элементы будут интерактивными. Но в приведенном ниже примере вы не можете щелкнуть заголовок «Рекомендации» для просмотра рекомендаций. В этом случае мы можем рассмотреть изменение цвета заголовка на черный или сделать заголовок интерактивным.
Красный заголовок на сайте библиотеки, который не является интерактивным.
Важно отметить, что эти решения могут изменить общую эстетику сайта. Мы могли бы решить, что ссылки и призывы к действию должны быть красным, а не синим, но это может привести к более заметному общему изменению эстетики интерфейса - внезапно появятся намного больше красных элементов в пропорции к синему.
В интерфейсе FutureLearn мы рассмотрели вопрос об изменении квадратных форм, используемых в модуле прогресса курса, на круги, прежде чем мы поняли, что навигация по курсу - это шаблон подписи, а замена форм изменила бы восприятие бренда.
Понимание шаблонов подписей может помочь вам найти правильный баланс между улучшением и обеспечением того, чтобы вы не ослабляли и не разбавляли существующую эстетику. Если ваша цель состоит в том, чтобы изменить текущий дизайн, это должно быть сделано до систематизации. 5
Во время инвентаризации цвета нередко обнаруживаются десятки вариаций одного и того же цвета (Марцин Трейдер обнаружил 62 оттенка серого во время инвентаризации цвета для UXPin 6 ). Большинство из них являются ненужными и создают ненужные сложности в дизайне и коде.
Цель этого шага - сделать цветовую палитру более сфокусированной, точной и доступной. Обычно это включает в себя уменьшение количества переменных для каждого цвета.
Вот несколько советов, которые могут быть полезны в этом процессе.
Преимущество целенаправленного инвентаря заключается в том, что он помогает вам ориентироваться и ограничивать выбор цвета. Когда вы начинаете с роли и значения цвета, вы получаете представление о том, сколько вариантов вам действительно нужно. Рассматривая, где и как они будут использоваться, вы будете знать, например, что вам нужно только три варианта синего цвета.
Количество оттенков и оттенков будет варьироваться в зависимости от ваших обстоятельств. В интерфейсе FutureLearn мы целенаправленно избегали более темных и светлых разновидностей одного цвета, чтобы сохранить палитру четкой. Это помогло нам сделать систему цветов простой и целенаправленной.
С другой стороны, UXPin, инструмент для создания прототипов, имеет светлый и темный режимы, что означает, что цветовой палитре нужны оттенки и оттенки, чтобы обеспечить достаточный контраст в обеих настройках.
Основные и второстепенные цвета FutureLearn (слева) и некоторые цвета UXPin (справа) показывают, как различается потребность в изменении цвета в разных интерфейсах.
Иногда вам нужно иметь больше опций, особенно если есть несколько тем или вы имеете дело с визуализацией данных. Но важно избегать включения цветов, чтобы добавить больше разнообразия в вашу палитру. Чем больше вариантов выбора, тем сложнее система, тем сложнее добиться последовательного использования цвета. Начните только с того, что вам нужно, и опирайтесь на него.
Если у вас есть более двух вариантов одного и того же цвета, это поможет определить базовое значение, а затем добавить дополнительные оттенки и оттенки: на 20% светлее, чем основание, на 20% темнее, чем основание, и так далее. Значения основного цвета обеспечивают постоянные значения по умолчанию. Когда есть много вариантов для рассмотрения, значения по умолчанию и значимые приращения легче запомнить и работать с ними. Задание основного цвета и приращений также работает для других шаблонов восприятия, таких как типография (базовый размер шрифта), интервал (базовая единица измерения) и анимация, как мы увидим позже.
Проверьте цветовой контраст между текстом и фоном. Корректировка или удаление значений по мере необходимости будет ограничивать вашу палитру. Например, среди нескольких вариантов светло-серого цвета, используемых для поддержки ссылок на сайте библиотеки, одно из часто используемых значений соответствует стандартам WCAG 2.0. Это сделало бы очевидным выбор значения поддержки по умолчанию для ссылок.
Существует множество инструментов для проверки цветового контраста, таких как коэффициент контрастности Lea Verou 7 , который быстр и прост в использовании.
Проверка контрастности Лее Веру.
Стоит отметить, что для корректировки цветовых значений необходимо тщательно сбалансировать общую эстетику. Например, измените синий цвет на более темный, и весь интерфейс может внезапно почувствовать себя другим, возможно, менее ярким. Если ваша цветовая палитра была создана без учета доступности цвета в первую очередь, для правильного баланса потребуется некоторая затея. 8
Вы можете ввести различные цвета акцента для светлого и темного фона или изменить текст на цветном фоне со светлого на темный или наоборот. Существует также множество инструментов для создания контрастных цветовых комбинаций или для поиска доступных альтернатив оригинальному цвету, таких как Color Safe 9 и Tanaguru Contrast Finder 10 . 11
Наконец, согласитесь с несколькими основными принципами использования цвета. Руководящие принципы помогают вам подходить к цвету целостно, и к ним можно обращаться, когда что-то не работает. Некоторые принципы могут быть общими (например, «всегда используйте доступный цветовой контраст»); другие будут более специфичными для вашего бренда (и могут быть определены во время упражнения с образцами подписей).
Например, в наборе инструментов Sky 12 команда объясняет причины минимальной цветовой палитры:
«Мы позволяем нашему великолепному контенту быть тем цветом, который оживляет страницу. Мы не красим наши сайты или разделы внутри наших сайтов ».
Оксфордский университет 13 четко объясняет , как и почему использовать его цвет:
«(Темный) оксфордский синий используется главным образом в обычной мебели для страниц, такой как фоны в верхнем и нижнем колонтитулах. Это делает для сильного присутствия бренда по всему сайту. Поскольку в этих областях он имеет такие сильные стороны, не рекомендуется использовать его на больших площадях в других местах. Однако он используется реже в небольших элементах, таких как значки даты событий и панели поиска / фильтрации ».
Даже с более сложными шаблонами, такими как анимация, мы можем следовать одному и тому же процессу: начинать с цели, собирать и группировать существующие стили, определять шаблоны и строительные блоки. Давайте на этот раз возьмем FutureLearn в качестве примера.
Укажите роли, которые играет анимация. Например:
• Смягчить переходы между интерактивными состояниями, такими как состояния при наведении.
• Добавить акцент на конкретную информацию или действие; например, толчок, чтобы побудить пользователей перейти к следующему шагу.
• Скрыть и раскрыть дополнительную информацию , такую как скрытое меню, раскрывающийся список или всплывающее окно.
Ощущение анимации является еще одним важным аспектом , чтобы рассмотреть. В Проекте Анимации Интерфейса 14 Вэл Хэд объясняет, как прилагательные, описывающие качества бренда, могут использоваться для определения движения. Быстрое, мягкое, бодрое движение может быть воспринято как живое и энергичное, в то время как постоянные легкие выходы чувствуют себя уверенными и решительными. Чтобы анимация была содержательной и эффективной, она должна быть целеустремленной во всем интерфейсе.
Как только вы поймете, какую роль играет анимация в вашем интерфейсе и как она должна ощущаться, следующим шагом будет аудит существующих анимаций. Соберите анимации и сгруппируйте их по категориям, как мы делали с цветом ранее. Примеры могут быть записаны с помощью QuickTime или другого приложения для записи экрана.
Страница «Изменение состояния» из анимационного аудита FutureLearn, проведенного в документе Google 15 .
Определите образцы использования, основанные на цели и чувстве. В интерфейсе FutureLearn мы заметили, что анимация выделения обычно кажется более игривой, а переходы изменения состояния более тонкими и спокойными.
Если это те звуки, которые вы хотите воспроизвести по всей системе, попробуйте настроить все анимации на них. Как и в упражнении с шаблонами подписи, возьмите примеры, которые хорошо работают (то есть эффективно достигают цели и имеют правильное ощущение), и опробуйте их свойства с другими анимациями из той же категории. В итоге вы получите несколько шаблонов:
| Цель | Анимационные эффекты | Чувствовать |
|---|---|---|
| Интерактивное изменение состояния | Цвет , непрозрачность 2с легкость , в: 0,3с; Out: 1.1s Масштаб легкости , 0,4 легкости | Спокойный, мягкий |
| Информация раскрыть | Сползание вниз , 0,4 поворота Плавное движение вверх , 0,7 с облегчение FadeInUp , 0,3 легкость Поворот , 0,3 легкость | Спокойный, мягкий |
| акцент | Энергичный импульс , 0,3 с замедлением Легкий импульсный покачивание , 0,5 с замедлением | Энергичный, игривый |
Анимационные шаблоны на FutureLearn сгруппированы по целям и ощущениям.
В анимации есть два важных понятия, которые идут рука об руку: время и ослабление. Время - это сколько времени занимает анимация. В сочетании с расстоянием он определяет скорость. Ослабление определяет, как что-то анимируется: начинается ли оно медленно и наращивает ли скорость (замедление) или же оно запускается быстро и постепенно замедляется (замедление)? Кроме того, мы должны определить анимируемые свойства, такие как цвет, непрозрачность, масштаб и т. Д.
Время особенно важно в анимации. Правильный выбор времени - это не столько идеальная техническая согласованность, сколько уверенность в том, что время кажется правильным . Два элемента, анимированные с одинаковой скоростью, могут чувствовать себя совершенно по-разному, если они имеют разные размеры или путешествуют на разные расстояния.
Мне нравится 16- летняя идея Сары Драснер иметь дело с синхронизацией анимации, как мы имеем дело с заголовками в типографии. 17 Вместо одного значения начните с основы и предложите несколько дополнительных шагов. Например, если базовое время составляет 0,5 секунды, меньшие элементы, которые перемещаются на меньшее расстояние (например, масштабирование значков), будут занимать меньше времени. Пункты, которые перемещаются на большие расстояния (например, всплывающее меню), потребуют больше времени. Полноэкранный переход будет на один или два шага выше базового значения.
Если ваша команда еще не уверена в анимации, возможно, стоит определить общие принципы, такие как «Зарезервируйте анимацию для наиболее важных моментов взаимодействия» и «Не позволяйте анимации мешать выполнению задачи». Но наиболее полезные принципы обычно зависят от того, как ваша команда подходит к анимации. Например, принципы системы Salesforce Lightning Design 18 рекомендуют сократить время и уловить движение.
Руководящие принципы могут также включать пространственные метафоры, которые могут служить полезной мысленной моделью для аниматоров. Google Material Design 19 является отличным примером того, как просмотр интерфейса в виде физических материалов может стать общим ориентиром для дизайнеров и разработчиков, когда они думают о движении в своих приложениях. 20
Голос и тон в копировании пользовательского интерфейса играют основополагающую роль в восприятии продукта. Это особенно актуально для голосовых интерфейсов, но также и для людей, которые испытывают цифровые продукты с помощью чувств, отличных от зрения. В недавнем разговоре с Леонией Уотсон 21 , экспертом по специальностям, которая также является пользователем программы чтения с экрана из-за слепоты, она отметила, что ее опыт работы с цифровыми продуктами «часто проявляется в форме стиля письма» 22.
Тем не менее, члены команды, которые определяют взаимодействия и шаблоны, часто не являются теми же людьми, которые будут работать над голосом и тоном. Это может привести к неоднозначному и бездумному стилю письма. Чтобы убедиться, что голос и тон выражены последовательно и целенаправленно, дизайнеры, бренды и маркетологи должны координировать свои усилия при определении моделей.
Помимо сбора всей копии пользовательского интерфейса в документе Google, существуют более креативные способы аудита голоса и тона. В своем блоге 23 стратег по контенту Эллен де Фриз поделилась тем, как она « собрала » языковые паттерны во время обновления голоса и тона Clearleft из 24 : от фраз, которые люди используют на собраниях и презентациях, до неформальных бесед с основателями. Они даже создали доску настроения, чтобы увидеть, как язык и образы работают вместе на сайте Clearleft.
Инвентаризация голосовых и тональных рисунков для Clearleft.
Как только копия и другие материалы будут собраны, определите шаблоны и сформулируйте руководящие принципы для их применения в интерфейсе. MailChimp's Voice & Tone 25 является одним из наиболее эффективных примеров определения языковых шаблонов. Тон меняется, реагируя на эмоциональное состояние пользователя: когда уместно быть шутливым и беззаботным («Прекрасная работа»), и когда копия должна принимать серьезный практический тон («Мы ожидаем, что проблема в один из наших центров обработки данных »).
Аналогичным образом, Salesforce дает разбивку общих вариантов использования и предлагает шаблоны копирования для использования с каждым из них. Цель сообщения влияет на эмоциональный тон, такой как «предложить решение, используя легкомысленный язык».
Пример шаблонов голоса и тона в Руководстве по голосовым и тональным сигналам Salesforce
Как и общие принципы проектирования (см. Главу 2), руководящие принципы для отдельных стилей не должны быть расплывчатыми и общими. В Intuit's Harmony 26 перечислены не только принципы голоса и тональности («Веди себя впереди», «Не усложняй», «Веселись»), они также объясняют, как все это делать.
Голосовые и тональные инструкции Intuit объясняют, как применять принципы.
К каждому стилю следует подходить как к отдельной системе - типографика, система макетов, система цветов и т. Д. Они должны быть взаимосвязаны и направлены на достижение более широкой цели - чтобы помочь сформировать, как продукт воспринимается.
Чтобы сделать это, сначала посмотрите на общую картину. Запечатлейте эстетические качества в целом и определите модели, которые особенно эффективны при их выражении. Затем вы можете выполнить аналогичный процесс для всех стилей: начать с ключевых ролей, которые стиль играет в контексте вашего продукта, провести аудит существующих экземпляров, а затем определить шаблоны и строительные блоки. Руководящие принципы помогают связать все воедино и связать это с целью.
Давайте теперь рассмотрим библиотеки шаблонов как инструмент для документирования и обмена шаблонами.
-
2. См. Главу 4.
3. http://smashed.by/wetoolkit
4. http://smashed.by/coloraudit
5. Как объяснено в главе 8.
6. http://smashed.by/colorinventory
7. http://smashed.by/contrastratio
8. И наоборот, в проекте, где доступность цвета была фактором с самого начала, у вас не было бы столь разных палитр.
10. http://smashed.by/contrastfinder
11. Для дальнейшего ознакомления с доступностью цвета и балансом с эстетикой я настоятельно рекомендую Geri Coady: рабочие процессы доступности цвета .
12. http://smashed.by/skytoolkit
13. http://smashed.by/oxfordstyle
14. http://smashed.by/designingia
15. http://smashed.by/animationaudit
16. https://sarahdrasnerdesign.com/
17. http://smashed.by/animationdesignsys
18. http://smashed.by/salesforcemotion
19. http://smashed.by/materialmotion
20. Более подробный обзор процесса см. В моей статье « Интеграция анимации в систему проектирования ».
21. https://tink.uk/
22. Интервью с Леони Уотсон, август 2017
В этой главе мы рассмотрим некоторые практические приемы создания основы для долговечной и междисциплинарной библиотеки шаблонов.
Для некоторых команд системный подход к проектированию и созданию цифровых продуктов практически немыслим без библиотеки шаблонов. Но, как мы уже обсуждали в этой книге, библиотека шаблонов - это не сама система, а инструмент для документирования и обмена шаблонами проектирования. Чтобы быть эффективным, ему нужна основа системы. В главе 7 мы рассмотрели некоторые общие стратегии создания такой основы:
• Согласуйте основные цели и задачи, связанные как с интерфейсами, так и с тем, как работают команды, такие как «Определение и стандартизация многократно используемых шаблонов проектирования», «Определение руководящих принципов проектирования», «Создание библиотеки шаблонов».
• Разбейте цели на управляемые истории и создайте простую дорожную карту для вашей системы.
• Сделайте ваши успехи прозрачными, документируя и делясь им. Для многих команд обнародование их библиотеки шаблонов имело огромное значение для их прогресса и уверенности команды в работе, которую они выполняли.
• Создать культуру обмена знаниями, сделав язык дизайна видимым и доступным для всей команды.
• Тренируйте мышление в системах с помощью экспериментов, семинаров и групповых упражнений.
По опыту каждой команды, с которой я говорил, междисциплинарные библиотеки шаблонов более устойчивы и долговечны. Они способствуют общему языку в организации и приносят пользу каждому. И наоборот, библиотека шаблонов, созданная для удовлетворения потребностей одной дисциплины, является более хрупкой. 1
Техническая сложность первой библиотеки шаблонов Sipgate не позволила дизайнерам быть полностью вовлеченными. Без знания того, какие шаблоны существуют в системе, они иногда создавали страницу с нуля в Photoshop, где могли бы использоваться существующие шаблоны.
«Разработчикам часто оставалось адаптировать дизайн к существующим шаблонам, которым приходилось настраивать их до тех пор, пока они не будут соответствовать. Это привело к многочисленным операторам if, исключениям и дублирующимся шаблонам ».
- Матиас Вегенер, разработчик фронт-энда, Sipgate
Несмотря на то, что разработчики были полны решимости сделать библиотеку шаблонов всеобъемлющей и актуальной, это было невозможно без активного участия дизайнеров.
Точно так же шаблоны, разработанные без перспективы дисциплины контента, могут распадаться при повседневном использовании. В итоге мы разрабатываем шаблоны, которые слишком тесно связаны с конкретным контентом, например, модуль, в котором дополнительная строка копирования подтолкнет важный призыв к действию ниже видимой области. Или мы навязываем контент в шаблоны, которые не предназначены для него, ставя под угрозу как контент, так и дизайн.
В этой главе мы сосредоточимся на создании основ библиотеки шаблонов, которая может поддерживать цели нескольких дисциплин.
Оглядываясь назад, в FutureLearn мы потратили слишком много времени на изучение инструментов и разработку того, как должна выглядеть библиотека шаблонов. Не было полного согласия относительно того, как это должно быть спроектировано и построено, и работа продвигалась медленно. Переключение нашего внимания на содержание библиотеки имело большое значение - и для нашего прогресса, и для морального состояния команды.
Прохождение процесса, описанного в предыдущих двух главах, даст вам хорошее представление о том, что можно использовать в вашей библиотеке шаблонов. Это можно задокументировать просто, используя Google Docs 2 или другое приложение для совместной работы. Есть два основных преимущества этого:
• Во-первых, каждый в команде может получить доступ к содержимому, чтобы просмотреть, внести изменения и оставить свой отзыв. Используя знакомый и легко доступный инструмент, вы даете возможность большему количеству людей принять участие.
• Во-вторых, папка в Google Docs похожа на библиотеку шаблонов MVP - команда может сразу начать использовать в качестве справочной. Как только у вас будет контент, вам будет легче понять, как веб-сайт для него должен быть спроектирован и создан.
Вот как Эндрю Кулвелл (Andrew Couldwell) на WeWork 3 запечатлел некоторые шаблоны для системы проектирования плазмы 4 с помощью Google Docs:
Документирование шаблонов в Google Docs для системы проектирования Plasma.
Команда смогла быстро разобраться во всех основных шаблонах и их определениях, вместо того, чтобы сдерживаться ограничениями сборки и дизайна.
При документировании контента, скорее всего, возникнет вопрос о том, как следует организовывать шаблоны. Навигационная структура - это одна из вещей, о которой команды стремятся договориться. Должны ли кнопки быть отдельными или сгруппированными с элементами формы? Куда девается нижний колонтитул? Должна ли нумерация страниц быть частью раздела навигации?
Структура не обязательно должна быть идеальной в начале - вы можете (и, вероятно, измените ее) позже. Важно то, что команда находится на одной странице. Наличие общей методологии организации шаблонов облегчит добавление и поиск объектов по мере роста вашей библиотеки шаблонов. То же самое можно применить не только к библиотеке шаблонов, но и к интерфейсной архитектуре и файлам дизайна.
Давайте посмотрим на некоторые из общих подходов.
Самый простой способ думать о структуре с точки зрения компонентов и стилей (функциональных и перцептивных паттернов). Как мы видели в предыдущей главе, модели восприятия связаны и работают вместе. Абстрагирование их облегчает понимание их роли в системе. Вот несколько примеров того, как перцептивные и функциональные паттерны упоминаются.
| Библиотека шаблонов | Функциональные паттерны | Шаблоны восприятия |
|---|---|---|
| Airbnb DLS | Компоненты | Фонд |
| Атлассиан 5 | Компоненты | устои |
| BBC GEL 6 | Шаблоны проектирования | устои |
| IBM Carbon 7 | Компоненты | Стиль |
| Одинокая планета Риццо 8 | Компоненты пользовательского интерфейса | Элементы дизайна |
| Marvel 9 | Компоненты | дизайн |
| Офисная Ткань 10 | Компоненты | Стили |
| Система проектирования молний Salesforce 11 | Компоненты | Дизайн токенов |
| Shopify Polaris 12 | Компоненты | Визуальные |
Похоже, что существует общее согласие называть функциональные паттерны «компонентами», но больше терминологии, используемой для перцептивных паттернов.
Хотя количество стилей ограничено, список функциональных шаблонов может продолжать расти. Находимость модулей является одним из главных препятствий на пути принятия библиотеки шаблонов. Если члены команды не знают, что шаблон существует, или не могут найти то, что ему нужно, они могут создать новый или выйти за пределы системы шаблонов.
Команды организуют модули в алфавитном порядке, иерархически, по типу (навигация, элементы формы и т. Д.), По назначению или совершенно другими способами.
В системе IBM Carbon design компоненты Sky Toolkit 13 и Rizzo (среди прочих) Lonely Planet хранятся в одном списке и располагаются в алфавитном порядке.
Большинство компонентов расположены в алфавитном порядке в Rizzo Lonely Planet (хотя элементы навигации и формы находятся в отдельных группах).
Единый список облегчает принятие решений - он избегает споров о том, как вещи должны быть классифицированы. Если список увеличивается и становится неуправляемым, команды начинают экспериментировать с другими вариантами, чтобы сделать компоненты более доступными для обнаружения.
Другой способ классификации функциональных шаблонов заключается в их сложности. Некоторые команды отделяют гранулированные элементы от более сложных. Уровни детализации различаются по количеству и воспринимаемой сложности.
Атомный дизайн, впервые предложенный Брэдом Фростом, является популярным примером иерархической категоризации. Атомы являются основными строительными блоками, которые объединяются для создания более сложных автономных элементов: молекул . Например, метка формы, ввод и кнопка объединяются в форму поиска. Молекулы объединяются в организмы (например, заголовок сайта), а организмы - в шаблоны и страницы .
Компоненты расположены иерархически в GLU 14 Eurostar .
В качестве методологии атомный дизайн может принести много преимуществ. Думая о шаблонах как о матрешках, вложенных в матрешки, можно повторно использовать элементы, поскольку вы понимаете, как уровни строятся друг на друге. Определение правил для объединения и инкапсуляции шаблонов может способствовать согласованности во всей системе. Для команды в FutureLearn аналогия с химией дала общую точку отсчета, когда мы были новичками в мышлении модульного дизайна.
Но важно помнить, что атомарный дизайн (или любая другая методология) может быть не подходящим для вас прямо из коробки. В FutureLearn мы изо всех сил пытались найти применение «шаблонам» и «страницам». Команда предпочла работать с более мелкими элементами, чтобы мы могли иметь большую гибкость в том, как они были объединены.
Более того, мы провели слишком много времени, обсуждая, является ли что-то молекулой или организмом. Поскольку команда не видела достаточного различия между этими двумя типами, они были объединены. Мы получили два уровня иерархии: атомы и молекулы.
Более двух типов функциональных шаблонов могут привести к путанице, но имеет смысл отделять гранулированные элементы от более сложных - как в библиотеке шаблонов, так и в коде. Команды делают это в различной степени, с или без соблюдения атомной номенклатуры конструкции.
| Атомный дизайн 15 | атомы | Молекулы | микроорганизмы | Шаблоны |
| Перемирие Орегон 16 | элементы | Компоненты | - | - |
| ClearFractal 17 | Единицы | группы | - | - |
| GE Predix 18 | основы | Компоненты | Шаблоны | Особенности |
| Льюис + Хамфрис 19 | элементы | Компоненты | Композиции | - |
| WeWork's Plasma 20 | Компоненты | Узоры | - | - |
Что мне кажется интересным, так это то, что строгость системы (обсуждаемая в главе 6) может быть отражена в том, как структурирована библиотека шаблонов. Чем более детализированы шаблоны, тем более свободна и гибка система. В строгой системе, такой как Predix от Airbnb или GE, документируются более крупные шаблоны: пользовательские потоки, шаблоны и страницы. В такой системе, как TED или FutureLearn, вы должны документировать более мелкие детали и оставлять их на усмотрение отдельных дизайнеров.
В FutureLearn мы никогда не прекращали экспериментировать со способами организации модулей: в одном длинном списке, иерархически (следуя методологии атомного дизайна), по композиционной роли на странице («вступления», «выходы», «герои» и «мосты»). Но все было слишком ограничивающим или слишком сложным для работы.
После двух лет проб и ошибок мы остановились на классификации элементов по назначению - рекламные модули, модули, ориентированные на поощрение успеваемости учащихся, модули общения с пользователем, социальные модули и так далее.
Модули, упорядоченные по назначению в библиотеке шаблонов FutureLearn 21 .
Организация шаблонов по назначению дает команде некоторое руководство и вдохновение для того, где использовать определенный модуль. Эта структура также соответствует нашему целенаправленному подходу к определению шаблонов.
В Shopify Polaris компоненты также классифицируются на основе ментальных моделей команды. Первоначальная группировка была результатом открытого анализа карт и удобства использования. Даже при том, что не существует идеального выравнивания между различными дисциплинами, исследования внутренних пользователей непрерывно определяют, как организованы шаблоны:
«Дизайнеры склонны мыслить с точки зрения структуры. Разработчики склонны по умолчанию к функциональности. Контент-стратеги, как правило, объединяли оба. Мы проводим ряд исследований юзабилити, чтобы понять, насколько хорошо работает группировка компонентов для людей ». 22
- Селена Хинкли, контент-стратег, Shopify Polaris
Компоненты в Shopify Polaris упорядочены по структуре и функциям.
Это лишь некоторые из способов, которыми команды организуют шаблоны. Важно то, что выбор основан на том, как думают люди, которые его используют. Найдите структуру, которая подходит для вашей команды. Если это не сработает, если люди изо всех сил пытаются найти то, что они ищут, продолжайте экспериментировать с различными подходами. Это может занять время. Фраза, которую я больше всего слышу от всех команд с эффективными библиотеками шаблонов, заключается в том, что их «работа никогда не заканчивается».
Хотя многие вещи можно задокументировать вместе с каждым шаблоном, попытка охватить все сразу не представляется возможным, особенно для небольших команд.
Чтобы быстрее увидеть ощутимые преимущества, начните с упрощенного обзора основных моделей. Если у вас есть простая основа, вы можете со временем улучшать библиотеку шаблонов, добавляя функции и информацию, необходимые команде. Вот некоторые моменты, которые следует учитывать при документировании функциональных и перцептивных паттернов.
Чтобы сделать документацию ориентированной и легко сканируемой, начните с основ:
• имя
• цель
• пример (визуальный и кодовый)
• варианты
На протяжении всей книги я пытался подчеркнуть важность правильно подобранного имени. Хорошее имя является целенаправленным и запоминающимся, и воплощает цель шаблона. В идеале, кто-то должен быть в состоянии почерпнуть цель из названия, без необходимости читать описание. Чтобы сделать страницу более удобной для сканирования, имена должны быть заметными и отличаться от остального содержимого.
Имя каждого шаблона заметно отображается в IBM Carbon.
При просмотре библиотеки шаблонов большинство людей пропускают описания, особенно длинные. Вот почему они должны быть целенаправленными и конкретными: обычно достаточно одного или двух предложений, объясняющих, что такое шаблон и для чего он нужен. Несмотря на то, что это кажется простой задачей, на практике кратко и точно запечатлеть цель шаблона не так просто. Слишком часто мы придумываем смутные описания, которые не имеют большого практического значения.
Посмотрите, как команда Sipgate изначально описала компонент под названием «Showcase»:
«Используйте Showcase, чтобы представить несколько типов информации в мультимедийном файле».
Даже несмотря на то, что это на самом деле правильно, оно не отражает цели «Showcase», что повышает вероятность его неправильного использования или дублирования. Позже команда приняла новую практику для определения цели шаблона и написания описаний. Вот как это было применено к другому примеру:
«Сетка фактов - это короткий список фактов или интересной информации. Используйте Fact Grid, чтобы дать читателю немедленное впечатление о предстоящем контенте ».
Это второе описание гораздо более эффективно для объяснения того, для чего предназначен шаблон. Возможно, вы даже сможете визуализировать «таблицу фактов», просто прочитав эти два предложения.
Кроме того, существуют рекомендации по дизайну и содержанию, позволяющие шаблону достичь своей цели наиболее эффективными способами, такими как «Максимум 3 строки на факт» или «Максимум 12 фактов». Сотрудничество с дисциплиной контента может иметь неоценимое значение для определения этих параметров. правила.
Сетка фактов в библиотеке шаблонов Sipgate 23 .
Хороший пример помогает улучшить понимание цели шаблона. В руководстве по стилю Marvel примеры являются самодокументируемыми и показывают несколько вариантов и вариантов использования. Копия пользовательского интерфейса в шаблоне помогает в дальнейшем использовании.
В руководстве по стилю Marvel примеры позволяют легко увидеть, как ведут себя разные поповеры.
Меньший пример не помогает сообщить цель. Ничто в том смысле, как «Рекламный щит» представлен в библиотеке FutureLearn, не говорит о том, что это «выдающийся рекламный элемент». Внесение небольших корректировок, таких как изменение копии по умолчанию и фонового изображения, может помочь более четко выразить свое назначение.
«Billboard» в библиотеке шаблонов FutureLearn не вдохновляет.
Обычно предпочтение отдается живому экземпляру шаблона с кодом компонента, который может отображать отзывчивость, взаимодействия и анимацию. Но в некоторых случаях статическое изображение или GIF более полезны, особенно когда вам нужно показать определенное поведение или состояние, которое невозможно воссоздать в живом примере.
Carbon использует комбинацию живых и статических примеров, чтобы проиллюстрировать определенное поведение.
Представление вариантов рядом друг с другом, как набор, облегчает с первого взгляда, что доступно в рамках цели. Мало того, нам нужно знать, как варианты отличаются друг от друга. Хотя в Office Fabric представлены все варианты, они не объясняют различий между ними.
Варианты в офисной ткани.
Сравните это с презентацией Carbon, в которой четко указана цель каждого варианта.
Типы сборщиков даты и различия между ними четко объяснены в Carbon.
Точно так же в рекомендациях по дизайну Atlassian описывается, когда использовать кнопку каждого типа (хотя, с моей точки зрения, некоторые копии, такие как «Использовать, когда вам нечего доказывать», могли бы выиграть от большей точности).
Варианты кнопок описаны в рекомендациях по дизайну Atlassian.
Есть много других аспектов, которые могут быть важны для документирования, такие как:
• Управление версиями компонентов. Если продукты, поддерживаемые библиотекой шаблонов, получают значительные обновления, некоторые компоненты могут получить выгоду от документирования изменений в элементах API или пользовательского интерфейса по сравнению с предыдущими версиями. То же самое касается устаревших элементов и их замен.
• Члены команды. Перечисление людей, участвующих в создании шаблона, как пример Sky Toolkit 24 , может дать людям чувство причастности , а также поможет в будущем развитии.
• Связанные паттерны. Shopify Polaris 25 услужливо показывает альтернативы, если шаблон не совсем то, что вы ищете. Это может уменьшить вероятность дублирования шаблонов.
В зависимости от потребностей вашей команды, есть много другой информации, которая может быть включена. В своей статье «Вывод библиотеки шаблонов на новый уровень» Виталий Фридман поделился двумя контрольными списками: один для шаблонов, которые нужно документировать, а другой - для того, чтобы включить их в каждый шаблон. 26
При документировании шаблонов восприятия основное внимание уделяется строительным блокам - цветовой палитре, типографской шкале и т. Д. Но, как мы видели в предыдущей главе, также важно знать, как эти свойства используются и как они работают вместе. Вот несколько советов и примеров.
Представление цвета не обязательно должно быть ограничено списком переменных. В своей цветовой палитре руководство по стилю GOV.UK 27 полезно определяет использование цвета для текста, ссылок, фона и других ролей.
Цветовая палитра показывает шаблоны использования в руководстве по стилю GOV.UK.
Формат DOS и DONTS также может быть полезен, особенно, когда ожидается неправильное использование. В Shopify Polaris 28 индиго и синий являются основными цветами, используемыми для интерактивных элементов. В этом случае полезно явно указать, что синий цвет не следует использовать для кнопок, поскольку было бы разумно предположить иное.
Типографский раздел веб-стандартов правительства США 29 показывает пары типов и их рекомендуемое использование. Расширяемые примеры демонстрируют типографские обработки в контексте.
Веб-стандарты правительства США включают пары и их рекомендуемое использование.
Хотя мы разделяем стили и компоненты, чтобы с ними было легче работать, на практике они тесно взаимосвязаны. Даже если есть дубликаты, ссылки на стили на уровне модуля, а также отдельно, полезны. У кнопки есть много стилей, которые определяют, какой это тип кнопки (цвет, форма, стиль метки, переходы, интервалы и т. Д.). В то же время, некоторые из этих стилей могут быть применены к другим объектам - меню, ссылки, переключатели управления. Совместное использование стилей - это то, что заставляет эти объекты чувствовать, что они принадлежат к одной и той же системе.
В Carbon стили отдельного модуля, такие как цвет, отображаются на отдельной вкладке. Использование цветов также задокументировано отдельно.
В Carbon на цвета ссылаются как на уровне модуля, так и вместе.
Возьмем другой пример: интерактивные состояния. Как правило, мы видим их документированными только на уровне модуля: вот кнопка и ее состояние наведения. Но также полезно увидеть все государства вместе, с первого взгляда. Как состояние наведения относится к вторичным ссылкам? Для иконки кнопок? Для призрачных кнопок? Для вкладок управления? Почему в некоторых случаях контур меняется на сплошной, а в других изменяется значение цвета?
Отображение интерактивных состояний для FutureLearn в одной сетке позволило нам определить всеобъемлющие правила для интерактивных состояний и применять их последовательно по мере добавления большего количества интерактивных элементов.
Некоторые из интерактивных состояний в библиотеке 30 шаблонов FutureLearn показаны вместе.
Чтобы быть эффективными, шаблоны восприятия должны соединяться и работать вместе. Показывая отношения (между цветами, между типографикой и интервалом, между голосом и тоном и визуальными эффектами), вы помогаете сделать всю систему более связной.
Одни и те же значения цвета могут иметь совершенно разные эффекты при применении в разных пропорциях. Как заметил Майкл Мак-Уоттерс, слишком много или слишком мало красного цвета, TED может чувствовать себя как другой бренд. Цветовые чипы в руководстве 31 по стилю Open Table проясняют иерархию цветов.
Типография и расстояние также тесно связаны между собой. Большая, более контрастная типография требует больше пробелов. Меньший текст может потеряться в том же объеме, если вы не компенсируете это за счет уменьшения отступов. Даже если у вас есть ограниченный выбор предопределенных параметров интервалов (таких как 8px или 16px), у разных дизайнеров могут быть разные предпочтения - некоторые предпочитают более щедрый пробел, другим - более уютный. Значения могут быть согласованы, но это не означает, что визуальная плотность будет.
Чтобы помочь определить плотность и контрастность продукта, в интерфейсе FutureLearn мы попытались показать связь между типографикой и расстоянием.
• Просторные модули имеют высокий типографский контраст (большой заголовок, пропорциональный размеру основного шрифта) и большой интервал, чтобы сбалансировать высококонтрастную типографику.
• Обычные модули составляют большинство разделов FutureLearn. У них есть заголовок и интервал по умолчанию.
• Компактные модули имеют заголовки только немного больше, чем основная копия.
Некоторые типы разделов для FutureLearn.
Эти настройки также отражают назначение модулей. Эффектные рекламные разделы выигрывают от высококонтрастной типографии. С другой стороны, модули с поддерживающей функцией имеют тенденцию быть более компактными.
Наконец, в подавляющем большинстве современных библиотек шаблонов стили отображаются на отдельных страницах. Я вижу это как ограничение. Возможно, следующее поколение библиотек шаблонов может показать их более взаимосвязанными способами. Как доски настроения или коллажи элементов, стили могут быть представлены таким образом, чтобы показать, как они работают вместе, и выделить шаблоны подписи и отношения между различными элементами.
Команды с эффективными библиотеками шаблонов имеют систематические подходы, укоренившиеся в их рабочем процессе. Как именно, зависит от компании. Некоторые команды, такие как Airbnb, имеют строгие и точно определенные процессы с мощными инструментами. Другие гораздо более неформальные.
Один из основополагающих аспектов, о которых нужно договориться, заключается в том, как новые шаблоны будут добавлены в систему. Команда Nordnet выполняет простой трехэтапный процесс: 32
1. Отправьте дизайн в папку набора пользовательского интерфейса на Dropbox.
2. Обсудите включение шаблона в команду.
3. Документируйте любые включенные проекты в наборе UI. Добавьте новый дизайн в Craft Library, который будет автоматически распространен на всю команду.
Команда собирается каждые две недели, чтобы обсудить новые предложения. Они проходят через бэклог Trello и решают, должен ли модуль быть одобрен для включения или заархивирован.
Аналогичный рабочий процесс принят командами в Shyp 33 (используя GitHub для добавления и просмотра шаблонов), FutureLearn и многих других. Процесс не должен быть строгим, но важно иметь что-то на месте, которое обеспечивает, в некотором смысле, регулярный пересмотр шаблонов.
Чтобы убедиться, что формат представлений согласован, некоторые команды считают полезным иметь стандартный шаблон с простыми рекомендациями, такими как имя, описание, автор и дата. В FutureLearn материалы поступают непосредственно в библиотеку шаблонов, а не в основной файл дизайна, и существует неофициальное руководство по написанию описания шаблона. Он состоит из трех вопросов: что это? Для чего это? Как это достигает своей цели?
Распространенной проблемой, с которой сталкиваются команды, является отсутствие согласия относительно того, что представляет собой шаблон проектирования. Способ управлять этим - иметь общие критерии для добавления (а также обновления и удаления) шаблонов.
Два наиболее распространенных подхода:
• Каждый новый элемент на сайте также автоматически добавляется в библиотеку шаблонов. Это работает, если вы строго придерживаетесь шаблонов в системе. Должен быть процесс, который проверяет, существует ли уже подобный шаблон или можно ли изменить существующий (например, регулярный обзор новых шаблонов в команде). Без этих процессов риск заканчивается дублированием паттернов.
• Элементы добавляются только тогда, когда они используются повторно . Некоторые команды добавляют модули только при втором или даже третьем использовании. Идея состоит в том, что элемент должен зарекомендовать себя в качестве шаблона, прежде чем его добавят в систему, что помогает поддерживать библиотеку шаблонов в форме. При таком подходе важно видеть все, что создается, и эффективно общаться между командами. Журнал недокументированных шаблонов также должен храниться, чтобы у команды была полная видимость того, что доступно, даже если его нет в библиотеке шаблонов.
Также возможно основать ваше решение на возможном повторном использовании. В FutureLearn специфика назначения компонента используется в качестве критерия. Если элемент определен в общем виде, он с большей вероятностью будет использован в будущем. В этом случае он добавляется в библиотеку шаблонов. Если у нового компонента есть определенная цель (например, сезонная акция, модуль, связанный с определенным событием и т. Д.), Его можно рассматривать как одноразовый.
Следуя этому правилу, вся команда должна заботиться о том, как они определяют компоненты, а не делать что-то конкретное, если это не является абсолютно необходимым. Если кто-то вводит одноразовое предложение, ему следует поделиться им и объяснить, почему оно является конкретным. Иногда кто-то может найти модуль полезным для своих нужд. В этой ситуации мы переопределим шаблон как более общий и добавим его в библиотеку.
Другим аспектом, который следует учитывать, является практичность обновления документации, особенно если нет специальной группы.
Если вклад поступает от всех, вы должны быть строгими, чтобы убедиться, что они добавлены в библиотеку. Например, добавление компонента может быть частью истории его создания. Дизайнер и разработчик, создавший шаблон, несут ответственность за его добавление в библиотеку шаблонов. Как мы видели в главе 6, эта модель подходит не для каждой команды. Иногда вам нужен человек или группа людей, ответственных за настройку и поддержку библиотеки шаблонов, даже если каждый вносит свой вклад.
Если есть специальная команда разработчиков систем, важно согласовать их роль, а также процесс управления взносами. Системная команда может выступать в роли куратора или продюсера, и многие компании используют комбинацию обоих.
• Куратор. Вклады в новые шаблоны поступают со всей организации. Системная команда определяет способы участия внутренних групп, включая определение требований и процесс проверки. Если представленный шаблон не соответствует стандартам, команда рекомендует дизайнерам и разработчикам, которые его создали, изменить его, а не вносить изменения самостоятельно. Команда Atlassian следует этой модели.
• продюсер. При таком подходе команда разработчиков систем создает большинство шаблонов. Обычно они работают в тесном контакте с дизайнерами продуктов в разных командах и проводят открытые встречи, на которых другие могут задавать вопросы, давать отзывы или предлагать отсутствующие шаблоны. Системная команда принимает заявки от всей компании, но они имеют окончательное мнение о том, что включены, отрегулированы или удалены. Airbnb использует этот подход.
При выборе направления учитывайте свою организационную структуру, командную культуру и конкретные потребности в продукте. Роль куратора обычно подходит для распределенных групп с более слабыми системными структурами, тогда как производители чаще встречаются в более строгих и централизованных системах.
В обоих случаях важно, чтобы системная команда рассматривалась как партнеры , а не как полиция.
«Мы хотим сотрудничать с командами как можно раньше, когда они думают о разработке новых шаблонов и компонентов. Наши отношения с командами по продукту должны быть партнерством, а не ситуацией, когда кто-то уходит и выполняет кучу работы, а затем мы либо одобряем, либо налагаем вето. Если это произойдет, мы не очень хорошо выполняем свою работу ».
- Эми Тибодо, руководитель UX, Shopify
Код, дизайн и библиотека шаблонов - это аспекты одной и той же системы. Такой подход делает его более надежным, поскольку система поддерживается с нескольких точек зрения. Это не обязательно означает, что шаблоны должны быть полностью синхронизированы. Что важно, так это то, что команда применяет один и тот же подход во всех аспектах - к наименованию, структуре и пониманию цели.
Команда разработчиков Carbon старается быть максимально последовательной в своем наборе Sketch, библиотеке компонентов и коде.
В системе проектирования Carbon имена и структура папок соответствуют всем трем аспектам системы.
Дизайнеры Nordnet используют атомарный дизайн для организации папок в наборе Sketch. Они даже следуют правилам именования БЭМ для своих файлов дизайна, чтобы помочь разработчикам и дизайнерам говорить на одном языке. 34
Когда дизайн и код выровнены концептуально, легче добиться синхронизации между ними. Также проще найти инструменты, которые соответствуют вашему рабочему процессу.
Синхронизация библиотеки шаблонов с рабочим кодом является одной из основных задач. Команды используют разные подходы - от ручного копирования и вставки до создания библиотеки шаблонов частью производственной среды (Rizzo от Lonely Planet является примером последнего). Многие инструменты помогают достичь этого. Вот некоторые из самых популярных.
Одними из самых простых в реализации являются инструменты разбора документации CSS, такие как KSS 35 . Все они работают одинаково: комментарии в CSS предоставляют описание (которое запрограммировано вводится в документацию); при запуске скрипта генерируется разметка для библиотеки шаблонов. Инструменты синтаксического анализа относительно просты, но ограничены в функциональности. Они также могут привести к дублированию разметки, что может сделать обслуживание более трудоемким.
Среди более мощных инструментов - генераторы руководств по стилю, такие как Pattern Lab 36 Брэда Фроста, Дейва Олсена и Брайана Мюнзенмейера. Шаблон Lab поставляется с множеством полезных функций, таких как адаптивный предварительный просмотр и поддержка нескольких языков. Он преимущественно подходит для больших сайтов с несколькими шаблонами, особенно для тех, которые используют методологию атомного дизайна.
Fractal 37 от Mark Perkins - один из самых легких и гибких инструментов, который набирает популярность. Fractal помогает создавать и документировать библиотеку шаблонов и интегрировать ее в ваш проект. Одним из его основных преимуществ является то, что он гибок и незатронут - Fractal может работать с любым языком шаблонов и организационной структурой.
Полная синхронизация между библиотекой шаблонов и кодом чрезвычайно труднодостижима, и компании управляют ею с разной степенью успеха. Способы, которыми команды назначают приоритеты синхронизации, также различаются:
«Это всегда немного несинхронно. Если это слишком идеально, это не сработает. Наш язык дизайна, как и любой язык, постоянно развивается. Мы меняем детали и шаблоны и добавляем шаблоны. Мы постоянно строим продукты. Поэтому в любой момент времени существует множество версий языка дизайна. Мы учитываем этот факт и проектируем систему, которая может справиться с этими недостатками ».
- Юрген Шпангл, руководитель отдела дизайна, Atlassian
В более жестких системах и централизованной организации это важнее, тогда как компании с более слабой структурой более терпимы к несогласованности.
Дизайнеры, практикующие системный подход, в настоящее время склонны использовать Sketch 38 в качестве основного инструмента (в основном благодаря таким функциям, как стили текста, символы и монтажные области, которые, похоже, хорошо подходят для рабочего процесса системы проектирования). Команды, как правило, имеют главный файл, который содержит набор пользовательского интерфейса с некоторыми или всеми основными компонентами и стилями. Дизайнеры продуктов, как правило, работают из своих собственных файлов, вытягивая элементы из мастера по мере необходимости.
Задача состоит в том, чтобы удостовериться, что мастер-комплект всегда имеет последние образцы. Для этого есть множество инструментов - от легких до более комплексных решений.
Abstract 39 - это контролируемый версией хаб для ваших файлов дизайна. Вы можете создавать ветви, фиксировать исследования и объединять изменения. Аннотация упрощает сохранение единого источника правды для ваших файлов дизайна, включая набор мастер-интерфейса. Другой популярный инструмент - Invision's Craft 40 . Craft - это набор плагинов для Sketch, который синхронизирует пользовательский интерфейс с любым, у кого установлен плагин. Библиотека Craft может быть сохранена в Dropbox.
Более широкие возможности включают UXPin 41 , Brand.ai 42 и Lingo 43 . Эти инструменты позволяют создавать библиотеки шаблонов и управлять ими без использования кода. Естественно, они не обеспечивают такой гибкости, как настраиваемая библиотека шаблонов, но многие из них имеют полезные функции, такие как интерактивность компонентов, плагины Sketch 44 для поддержания файлов в актуальном состоянии, интеграция со Slack, которая пингует канал при обновлении библиотеки и многое другое.
Поскольку библиотеки шаблонов получают статус «источника правды», в некоторых компаниях стало несколько менее важно поддерживать совершенство основных комплектов пользовательского интерфейса. В FutureLearn мастер-файл Sketch (обновляется и публикуется через GitHub) содержит только основные гранулярные элементы, которые не склонны изменяться (типографика, кнопки, навигация и т. Д.). Дизайнеры используют библиотеку шаблонов в качестве основного справочника для современных шаблонов, Sketch или Photoshop используются главным образом для исследовательской работы. Поскольку большинство компонентов определены и названы, все чаще и чаще команда может обходиться с бумажными набросками, не требуя подробных спецификаций проекта.
Благодаря системам проектирования и библиотекам шаблонов рабочие процессы проектирования и разработки движутся навстречу друг другу. В этой области 45 много экспериментов , таких как инструменты для создания файлов Sketch непосредственно с веб-страницы и импорта реальных данных. В ближайшем будущем нам, возможно, не придется беспокоиться о синхронизации наборов пользовательского интерфейса, поскольку они могут быть сгенерированы в любое время из библиотеки шаблонов.
Инструменты должны соответствовать естественному рабочему процессу всей команды. Только тогда все станут собственниками, и вклады в библиотеку шаблонов будут равномерно распределены. Библиотека FutureLearn не имела возможности для дизайнеров обновлять описания модулей, что каким-то образом уменьшало их ответственность. Разработчики внешнего интерфейса были вынуждены постоянно обновлять документацию, что порой казалось обузой. Я надеюсь, что в будущем библиотеки шаблонов будут поддерживать междисциплинарный рабочий процесс. Они могут стать средой, в которой все дисциплины могут способствовать обсуждению шаблонов проектирования и помогают определить их цель.
Благодаря совершенствованию инструментов библиотеки шаблонов и системный подход к дизайну будут и впредь оказывать глубокое влияние на дизайнеров и разработчиков. Многие команды уже видят изменения. То, что раньше занимало несколько дней ручной работы, можно сделать за считанные минуты - без более подробных спецификаций проектирования, без переизобретения одних и тех же решений снова и снова. Поначалу это может показаться угрожающим (Будем ли мы работать в ближайшие годы? Это отвлекает от творчества и мастерства в сети?). Но, возможно, дело обстоит наоборот. Системы проектирования высвобождают наше время и энергию для решения более крупных и значимых задач, таких как более глубокое понимание наших пользователей и расширение возможностей языков проектирования.
-
1. Существует много других типов проектной документации, таких как документы, удостоверяющие личность бренда, руководства по стилю интерфейса для клиентов и т. Д. В этой главе мы говорим только о библиотеках шаблонов, созданных внутренними командами для поддержки системы проектирования.
5. http://smashed.by/atlassianpl
7. http://carbondesignsystem.com/
10. http://smashed.by/officefabricpl
11. https://www.lightningdesignsystem.com/
12. https://polaris.shopify.com/
13. http://smashed.by/skycomponents
14. https://style.eurostar.com/
15. http://smashed.by/atomicdesign
16. http://smashed.by/ceasefire
17. http://smashed.by/clearfractal
19. https://medium.com/@lewisplushumphreys
20. http://smashed.by/plasmads
21. https://www.futurelearn.com/pattern-library
22. Из электронной переписки с Эми Тибодо, руководителем UX на Shopify, август 2017 г.
23. https://design.sipgateteam.de/
24. http://smashed.by/skytoolkit
25. http://smashed.by/polarisnav
26. http://smashed.by/pattern2doc
28. http://smashed.by/polariscolor
30. http://smashed.by/flstates
31. http://smashed.by/opentable
32. См. « Простая документация по атомному проектированию с приложением Sketch » Росса Малпаса.
34. См. « Рабочий процесс Atomic для проектирования и разработки в Nordnet » Росса Малпаса.
38. https://www.sketchapp.com/
39. https://www.goabstract.com/
В программировании и дизайне шаблонная дисциплина Кристофера Александра стала одной из наиболее широко применяемых и важных идей. Теперь это влияет на то, как многие из нас думают о системах проектирования. Но есть существенная особенность, которую мы все еще можем упустить из первоначальной идеи Александра: моральный императив создавать системы, которые вносят позитивный вклад в человеческую жизнь.
В своей основной речи для OOPSLA 1 в 1996 году Александр подчеркнул, что в основе языка архитектурных шаблонов лежит фундаментальный вопрос: улучшат ли эти модели человеческую жизнь в результате их внедрения в систему? Даже если не все из них будут обладать такой способностью, необходимо по крайней мере постоянно прилагать усилия для ее достижения. 2
Теперь можно управлять многими аспектами нашей жизни в Интернете: от покупки продуктов и оплаты счетов до поиска даты или получения степени. Как архитекторы систем проектирования, мы играем важную роль в формировании цифрового мира. Язык шаблонов дал нам формат для размышлений о дизайне, а также поставил перед нами задачу: оказывают ли создаваемые нами шаблоны позитивное влияние на жизнь человека? Как мы узнаем, что они делают? Как мы постоянно проверяем это?
Трудно тщательно обдумать эти вопросы, когда вам задают задачу оптимизировать количество кликов или побуждают людей проводить больше времени на сайте. Даже с самыми благими намерениями, многое из того, что мы создаем в сети, предназначено для краткосрочной коммерческой выгоды, а не для того, чтобы приносить реальную ценность в повседневную жизнь: модели, разработанные для того, чтобы зацепить пользователей 3 , модели, ориентированные на некоторые группы населения, модели, которые поощряйте людей тратить время и деньги таким образом, о чем они могли бы сожалеть позже.
С другой стороны, мы не всегда учитываем, например, что происходит со всеми нашими цифровыми учетными записями и информацией, когда кто-то умирает, как создаваемые нами проекты улучшают чье-то качество жизни или насколько инклюзивными и чуткими являются наши системы.
Язык шаблонов для веб-сайтов, который мы создаем, очень мощный. Он способен влиять не только на цифровой мир, но и на физический. Мы в долгу перед собой и людьми, которые используют наши продукты, постоянно обдумывать и оспаривать форму, которую принимает этот язык, и быть внимательными к тому, что мы вносим в него.
Эти три книги являются отличным источником знаний и вдохновения для всех, кто интересуется проектированием систем. Я продолжал ссылаться на них снова и снова, когда писал эту книгу.
• Вечный путь строительства 4 Кристофер Александр
• Мышление в системах: учебник для начинающих 5 от Donella Meadows
• Как строят здания: что происходит после того, как они были построены 6 Стюартом Брэндом
Смотрите также:
• Как разобраться в любом беспорядке 7 Эбби Коверт
• Руководство по стилю переднего конца 8 Анной Дебенхем
• Атомный дизайн 9 Брэдом Фростом
• Адаптивный дизайн: образцы и принципы 10 Итана Маркотта
• Шаблоны Inclusive Design 11 по Heydon Pickering
• Design Systems Slack Team 12 , созданная Джиной Энн
• Дизайн системы статей 13 Натан Кертис
• Руководство по стилю Podcast 14 , организованное Анной Дебенхэм и Брэдом Фростом
• Design Systems Newsletter 15 , куратор Стюарт Робсон
• Отзывчивый веб-дизайн подкаста 16 , организованный Карен МакГрейн и Итаном Маркоттом
• Руководство по стилю сайта Ресурсы 17
Спасибо за чтение. Эта книга действительно только начало разговора о проектировании систем. Я хотел бы продолжить это за пределами книги, и был бы рад, если вы напишите мне по адресу alla@craftui.com со своими мыслями и историями.
-
1. Конференция ACM по объектно-ориентированным программам, системам, языкам и приложениям.
2. См. « Образцы в архитектуре » Кристофера Александра.
3. См. « Как технология угоняет ваш разум - от мага и специалиста по дизайну Google » Тристана Харриса.
7. http://smashed.by/makesense
10. http://smashed.by/rwdpatterns
11. http://smashed.by/inclusivedesignpatterns
Глава 1, Руководство по визуальной громкости: http://smashed.by/visualloudness
Глава 1, Руководство по стандартам графики НАСА: http://smashed.by/nasastandards
Глава 1, Музей американского искусства Уитни: https://www.experimentaljetset.nl/
Глава 4, Сайт кампании The Washington Examiner 2012: Саманта Уоррен, http://styletil.es/
Глава 4, Элемент коллаж для RIF: Дэн Молл, http://danmall.me/
Глава 5, Миньоны и Гру: Гадкий Я, © Universal Pictures
Глава 6, Puma City, LOT-EK: «Шкатулка» Сибил Крамер
Глава 6, Гриндо, Кейта Нагата: http://www.designboom.com
Глава 6, Корзинные квартиры, архитекторы OFIS: http://www.archdaily.com и http://www.ofis-a.si/
